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INTRODUCTION 



The documents in this collection have been gathered together 
and reprinted in order to provide information pertaining to 
BLISS-10 not found in the BLISS-10 Reference Manual (DECUS 10- 
118, PDM 001-326-002-01). These documents serve three primary 
purposes. They provide a general description of the language and 
explain some of the basic^ rather unique features of BLISS-10. 
They provide the background for a number of critical design 
choices in the language. Finally, they include examples and 
descriptions of some of the support software written for BLISS-10 
as an aid to using the language. 

The material presented in this document is for information 
purposes only. Digital Equipment Corporation makes no 
commitment to support any of the software as described herein. 

Our thanks go to Professor William A. Wulf , professor 

D. Russell, and Professor A. N. Habermann; also C. Ge^schke, 

J. Apperson, D. Wile and others at Carnegie-Mellon University 

through whose efforts the BLISS language was specified and 

implemented. 
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ABSTRACTS 

Wulf, W. A. et. al . , "BLISS - A Language for Systems Programming" 

This paper discusses the design considerations in 
constructing a language especially suited for use in 
writing production software systems, e.g., compilers, 
loaders, and operating systems, BLISS, a language 
implemented at Carnegie -Me lion University for use in 
implementing software for the PDP-10, is described to 
illustrate the result of these considerations. Some 
comments are made on early experiences using BLISS for 
implementing various types of systems. 



Geschke, C. ejt. al . , "BLISS Examples" 

This section contains a set of examples which illustrate 
the use of Bliss. Each example is intended to be fairly 
complete and self contained, and to illustrate one or 
more features of the language. 



Wulf, W. A. , "Programming Without the GOTO" 

It has been proposed by Dijkstra and others that the 
use of the GOTO statement is a major contributing factor 
in programs which are difficult to understand and debug. 
This suggestion has met with considerable skepticism 
in some circles since GOTO is a control primitive from 
which a programmer may synthesize other, more complex, 
control structures which may not be available in a given 
language. This paper analyzes the nature of control 
structures which cannot be easily synthesized from simple 
conditional and loop constructs. This analysis is then 
used as the basis for the control structures of a 
particular language, BLISS, which does not have a GOTO 
statement. The results of two years of experience programming 
in BLISS, and hence without GOTO ' s , are summarized, 

Wulf^ Wo A./ "Why the DOT?" 

An explanation of the pointer and contents concepts in 
BLISS justifying the semantic meaning of the dot operator. 
The current meaning is compared to possible alternative 
interpretations . 



wile, D, A. and C. M. Geschke, "Efficient Data Accessing in 

the Programming Language BLISS" -^ 

The specification of data structure in higher-level 
languages is isolated from the related specifications of 
data allocation and data type. Structure specification 
is claimed to be the definition of the accessing (addressing) 
function for items having the structure. Conventional 
techniques for data structure isolation in higher-level 
languages are examined and are found to suffer from 
a lack of clarity and efficiency. 

The means by which data structure accessors may be defined 
in BLISS, the specification of their association with 
named allocated storage, and their automatic invocation 
by reference to the named storage only, are discussed. 
An example is presented which illustrates their efficient 
implementation and their utility for separating the 
activities of data structure programming and algorithmic 
programming , 



Wulf, W. A., "HELP. DOC" 

DDT may be used to debug programs written in BLISS; 
however, the use of DDT alone requires a fairly detailed 
knowledge of the run-time stack and other run -time 
characteristics of BLISS programs and is not especially 
convenient. In particular, DDT cannot exploit any special 
information about the structure of the object program. 
A module called "HELP" has been written to augment the 
facilities of DDT. This module may be loaded (along with 
DDT) with any BLISS program — although recompilation of 
HELP is necessary if the user is not using the standard 
BLISS system registers. HELP is written in BL±SS and 
therefore the facilities described below may be called 
directly from the user's source program even though 
they are primarily intended for use from DDT. 
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Wulf, W. A., "HELP.BLI" 

This is the BLISS-10 source listing for the debugging aid 
described in HELP. DOC. 



Newcomer, J. M. , "TIMER.DOC" 

This is the reference document and user manual for a package 
written in BLISS-10 which gathers a number of timing _ 

statistics for programs written in BLISS-10. ^ 
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BUSS 
A LANGUAGE FOR SYSTEMS PROGRAMMING 



W. A. Wulf, D. B. Russell, A. N. Habermann 
Carnegie-Mellon University* 
Pittsburgh, Pa. 



ABSTRACT 

This paper discusses the design considerations in constructing 
a language especially suited for use in writing production soft- 
ware systans, e.g., compilers, loaders, operating systems, etc. 
Bliss, a language implemented at Carnegie -Mel Ion University for 
use in implementing software for the PDP-10, is described to 
illustrate the result of these considerations. Some comments 
are made on early experiences using Bliss for implementing 
various types of systems. 



INTRODUCTION 

In the fall of 1969 Carnegie -Me lion University 
acquired a PDP-10 from Digital Equipment Corporation 
to support a research project on computer networks. 
This research will involve the production of a sub- 
stantial number of large systems programs of the 
type which have usually been written in assembly 
language. At an early stage of this design effort 
it was decided not to use assembly language, but 
rather sane higher level language. This decision 
immediately leads to another question: which lan- 
guage? In turn this leads to a consideration of the 
characteristics, if any, which are unique to, or at 
least exaggerated in, the production and maintenance 
of systems programs. The product of these delibera- 
tions was a new language which we call Bliss. 

We refer to Bliss as an "implementation lan- 
guage", IL, although we admit that the term is some- 
what ambiguous since, presumably all computer lan- 
guages are used to implanent something . To us the 
phrase connotes a general -purpose, higher-level lan- 
guage in which the primary emphasis has been placed 
upon a specific application, namely the writing of 
large, production software systems for a specific 
machine. Special purpose languages, such as compil- 
er-compilers, do not fall into this catagorization, 
nor do we necessarily assume that these languages 
need be machine -independent. We stress the word 
'implementation' in our definition and have not used 
words such as 'design' and 'documentation'. We do 
not necessarily expect that an implementation lan- 
guage will be an appropriate vehicle for expressing 
the design of a large system nor for the exclusive 
documentation of that systen. Concepts such as 
machine -independence, expressing the design and 
implementation in the same notation, self -documenta- 
tion, and others, are clearly desirable goals and 
are criteria by which we evaluated various languages. 
However, they are not implicit in our definition of 
the term "implementation language". There are a few 
extant examples of languages which fit our defini- 
tion: EPL (a PL/i derivative used on MULTICS^) , 
B5500 Extended Algol (Burroughs Corporation^) , 
PL/3603, and BCPL^. 

''This work was supported by the Advanced Research 
Projects Agency of the Office of the Secretary of 
Defense (F-44620-67-C-0058) and is monitored by the 
Air Force Office of Scientific Research. 



The various arguments for and against the use 
of higher level languages to write systems software 
have been discussed at length. We do not intend to 
reproduce them here in detail except to note that 
the skeptics argue primarily on two grounds: effi- 
ciency, and an assertion that the systems programmer 
must not allow anything to get between himself and 
the machine. The advocates argue on the grounds of 
production speed (and cost), maintainability, re- 
design and modification, under standability and cor- 
rectness. The report of the NATO Conference on ^ 
Software Engineering held in Garmish (October, 1968) 
contains several discussions on these points, and 
the reader is urged to read that report. 

It is our opinion that program efficiency, 
except possibly for a very small ntmiber of very 
small code segnents, is determined by overall pro- 
gram design and not by locally tricky, "bit-picking" 
coding practices. 

Many, if not all, systems have experienced sub- 
stantial performance improvements from redesign or 
restructuring resulting from understanding or in- 
sight after the systan has been running for some 
time. This redesign is frequently done by someone 
other than the program^ s original author. This 
argues for good documentation - but also for under - 
standability of the code itself. Understandability 
is a function of many things, not all of which are 
inherent in the language in which a program is writ- 
ten - a programmer's individual style for example. 
Nevertheless, the length of a program text and the 
structure imposed upon that text are important fac- 
tors and argue strongly for the use of a higher lev- 
el language. 

Prestjoning the decision to use an implementation 
language, which one should one choose? An argument 
might be made for choosing one of the existing lan- 
guages, say Fortran, PL/i, or APL, and possibly ex- 
tending it in seme way rather than adding to the 
tower of Babel by defining yet another new one. We 
have chosen to do the latter and sOTie justification 
is required. The only valid rationale for creating 
a new language is that the existing ones are inap- 
propriate to the task. What then are the special 
characteristics of systems programs which existing 
languages are inappropriate to express? (Later we 
shall discuss how these manifest themselves in 
Bliss.) The two special characteristics most 
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frequently mentioned are efficiency and access to 
all hardware features of the machine. We add sev- 
eral things to these; the resulting list forms the 
design objectives of Bliss, 

Requirements of Systems Programs 

- space/ time economy 

- access to all relevant hardware features 

- object code should not depend upon elab- 
orate run-time support 

Characteristics of Systems Programming Practice 

- control over the representation of data 
structures 

- flexible range of control structures (no- 
tably including recursion, co-routines, 
and asynchronous processes) 

- modularization of a system into separately 
compilable sub -modules 

- parameterization, especially conditional 
compilation 

Overall Good Language Design 

- encourage program structuring for under- 
standability 

- encourage program structuring for debugging 

- economy of concepts (involution), general- 
ity, flexibility,... 

- utility as a design tool 

- machine independence 

Not all of the goals mentioned above are com- 
patible in practice, nor is the order in the above 
list accidental. Those found early in the list we 
consider to be absolute requirements while those 
occurring later in the list may be thought of as 
criteria by which alternative designs are judged 
once the more demanding requirements are satisfied. 

For example, efficiency, access to machine fea- 
tures and machine independence are conflicting 
goals. In fact the design of Bliss is not machine 
independent, although the underlying philosophy and 
much of the specific design are. The machine for 
which the language was being designed, the PDP-10, 
was ever present in the minds of the designers. The 
code to be generated for each proposed construct, or 
form of a construct, was considered before that con- 
struct was included in, or excluded from, the lan- 
guage. Thus the characteristics of the target 
machine pervade the language in both overt and sub- 
tle ways. This is not to say that Bliss could not 
be implemented for another machine, it could. It 
does say that Bliss is particularly well suited to 
implementation on the PDP-10 and that it could 
probably not be as efficiently implemented on 
another machine. We think of Bliss as a member (the 
only one at present) of a class of languages similar 
in philosophy and mirroring a similar concern for 
the important aspects of systems programming, but 
each suited to its own host machine. 

As another example of the incompatibility of 
these goals, consider the requirement for minimal 
run-time support and the use of the implementation 
language as a design tool. In some sense a design 
tool should be at a higher level than the object 
being designed - that is, the tool should relieve 
the designer from concern whichever details the 
designer deems appropriate only for later considera- 
tion. Any language relieves its user from concern 
over certain details, even assembly language frees 
the coder from the need to make specific address 



assignments. Assembly language is not a good design 
tool precisely because the class of such facilities 
is finite and narrow, a higher level language is 
better because the class is larger and broader. 
There is a point, however, beyond which broadening 
the class of details which are handled automatically 
introduces substantial costs in run-time efficiency 
and requisite run-time support. The design of Bliss 
walks a very fine line between generality, effici- 
ency, and minimal run-time support. At the time of 
this writing Bliss programs require run-time support 
to the extent of one subroutine consisting of ten 
instructions. 

DESCRIPTION OF BLISS 

Bliss may be characterized as an Algol-PL/l 
derivative in the sense that it has a similar expres- 
sion format and operator hierarchy, a block struc- 
ture with lexically and dynamically local variables, 
similar conditional and looping constructs, and 
(potentially) recursive procedures. As may be seen 
from the two simple examples shown below the general 
format of Bliss code is quite Algol-like; however, 
the similarity stops shortly beyond this glib com- 
parison. 

function factorial (n) = 

if .n leg 1 then else .n"factorial (.n-1); 

function QQsearch (K) = 
begin register R,Q,A,E; 

E ♦- R ♦- .K/.n; Q «- .K mod .n; A *- .const; 
do if .ST[.R] e£l .K 

then return .R 

else (R ♦- .R + .A; A «- .A + ,Q) 
until .R eql .E 
end; 

The first of these examples is the familiar recur- 
sive definition of factorial. The second example is 
the "quadratic quotient" hash search described by 
J. Bell in the February, 1970 CACM. 

We will now describe the major features of Bliss 
in terms of its major aspects: (1) the underlying 
storage, (2) control, (3) data structures, and final- 
ly mfention some other miscellaneous features. 

1. Storage 

A Bliss program operates with and on a number 
of storage "segments". A storage segment consists 
of a fixed and finite number of "words", each of 
which is composed of a fixed and finite number of 
"bits" (36 for the PDP-10). Any contiguous set of 
bits within a word is called a "field". Any field 
may be "named", the value of a name is called a 
"pointer" to that field. In particular, an entire 
word is a field and may be named. 

In practice a segment generally contains either 
program or data, and if the latter, it is generally 
integer numbers, floating point numbers, characters, 
or pointers to other data. To a Bliss program, how- 
ever, a field merely contains a pattern of bits. 
Various operations may be applied to fields and bit 
patterns such as fetching a bit pattern (value) from 
a field, storing a bit pattern into a field, integer 
arithmetic, comparison, boolean operations, and so 
on. The interpretation placed upon a particular bit 
pattern and consequent transformation performed by 
an operator is an intrinsic property of that operator 
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and not of its operands. That is ta say, there is 
no 'type' dlfferentation as in Algol. 

Segments are introduced into a Bliss program by 
declarations, for example: 

global g; 

own x,y [5], z; 
local p [100]; 
register rl, r2 [3]; 
function f(a,b) = .at.b; 

Each of these declarations introduces one or more 
segments and binds the identifiers mentioned (e.g., 
g, X, y, etc.) to the name of the first word of the 
associated segment. (The function declaration also 
initializes the segment named 'f to the appropriate 
machine code.) 

The segments introduced by these declarations 
contain one or more words, where the size may be 
specified (as in " local p[100]'*), defaulted to one 
as in " global g;"), or defaulted to whatever length 
is necessary for initialization (as in the function 
declaration). Explicit size declaration (as in 
" local p[100]") are restricted to expressions whose 
value can be determined at compile time so that run- 
time storage management is not required. The iden- 
tifiers introduced by a declaration are lexically 
local to the block in which the declaration is made 
(that is, they obey the usual Algol scope rules) 
with one exception - namely, "global" identifiers 
are made available to other, separately compiled 
modules. Segments created by own, global , and 
function declarations are created only once and are 
preserved for the duration of the execution of a 
program. Segments created by local and register 
declarations are created at the time of block entry 
and are preserved only for the duration of the exe- 
cution of that block. Register segments differ from 
local segments only in that they are allocated from 
the machine's array of 16 general purpose (fast) 
registers. Re-entry of a block before it is exited 
(by recursive function calls, for example) behaves 
as in Algol, that is, local and register segments 
are dynamically local to each incarnation of the 
block. 

It is important to notice from the discussion 
above that identifiers are bound to names by these 
declarations, and that the value of a name is a 
pointer. Thus the value of an instance of an iden- 
tifier, say X, is not the value of the field named 
by X, but rather is a pointer to x. This interpre- 
tation requires a "contents of" operator for which 
the symbol "." has been chosen. (Which explains the 
occurrence of this character in the earlier examples. 
This will be discussed in much greater detail under 
the subject of data structures.) There are two ad- 
ditional declarations whose effect is to bind iden- 
tifiers to names, but which do not create segments; 
examples are: 

external s; 

bind y2 - y+2, pa = p+.a; 

An external declaration binds one or more iden- 
tifiers to the names represented by the same name 
declared global in another, separately compiled 
module. The bind declaration binds one or more 
identifiers to the value of an expression at block 
entry time. This will be discussed in greater 
detail in the section on data structures. 



2 . Control 

Bliss is an "expression language", that is, 
every executable construct, including those which 
manifest control, is an expression and computes a 
value. There are no statements in the sense of 
Algol or PL/i. Expressions may be concatenated with 
a ";" to form compound expressions, where the value 
of a compound expression is that of its last compo- 
nent expression. Thus ";" may be thought of as a 
dyadic operator whose value is simply that of its 
righthand operand. The grouping symbols " begin" and 
" end " or "(" and ")" may be used to embrace such a 
compound expression and convert it into a simple 
expression. A block is merely a special case of 
either of these constructions which happens to con- 
tain declarations, thus the value of a block is 
defined to be the value of its constituent compound 
expression. 

The assignment operator, "«-", is a dyadic oper- 
ator whose left operand is interpreted as a pointer 
and whose right operand is an uninterpreted bit pat- 
tern. The right operand is stored into the field 
named by the left operand, the value of the expres- 
sion is that of its right operand. Recalling the 
interpretation of identifiers and the "." operator, 
the expression 

x*-.x+l 

causes the value of the field named by x to be in- 
cremented by one. The value of the entire assign- 
ment expression is that of the incremented value. 
The compound expression 

(y «- x; z *- ..y+1) 

causes a pointer to x to be stored into y, then 
computes the value of the field named by x (accessed 
indirectly through y) plus one and stores this value 
in z; this value is also that of the compound expres- 
sion. 

There is the usual complement of arithmetic, 
logical, and relational operators. Logical opera- 
tors operate on all bits of a word; relational oper- 
ators yield a value 1 if the relation is satisfied 
and a value of otherwise. 

We will describe six forms of control expres- 
sions: conditional, looping, case-select, function 
call, co-routine call, and escape. For this discus- 
sion it will be convenient to use the S3mibol 6, pos- 
sibly subscripted, to represent an arbitrary expres- 
sion. 

The conditional expression is of the form 

if €, then ^ else ^ 

and is defined to have the value €2 j^st in the case 
that the rightmost bit of G is a 1 and has the 
value of €0 otherwise. The abbreviated form "if ^^ 
then £," is considered to be identical to "i£ €, 
then €0 else 0". 



There are four basic forms of looping expres- 



sions: 



while €, do € 
do € while €1 
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incr <name> from €n to G^ b^ €- do g 
deer <name> from 6, to €2 by 6>. do € 

Each form of looping expression implies repeated 
execution (possibly zero times) of the expression 
denoted £ until a specific condition is satisfied. 
In the first form the expression (while... do) € is 
repeated so long as the rightmost bit of €■, remains 
1. The second form is similar to the first except 
that 6 is evaluated before G, thus guaranteeing at 
least one execution of €. The last two forms are 
similar to the familiar "step. . .until" construct of 
Algol, except (1) the control variable is local to 
€, (2) ^i>^> and ^ are computed only once (before 
entry to the loop) , and (3) the direction of the 
step is explicitly indicated ( incr ement or decre- 
ment). Except for the possibility of an escape ex- 
pression within € (see below) the value of a loop 
expression is uniformly taken to be -1. 

We shall treat somewhat simplified versions of 
the case and select expressions here, these forms 
are: 



case e of set €q; €1 ; . 
select e of^ nset 6^ : €■, ; 



^:k'- 



€ tes 
n 



^^'^-.■> tesn 



^n+1 



The value of a case expression is € > that is, the 
expression e is evaluated and this value is used to 
select one of the expressions 6. (0 ^ i ^ n) whose 
value, in turn, becomes the value of the entire case 
expression. The select expression is somewhat sim- 
ilar to the case expression with the distinction 
that the value of e is not restricted to the range 
^ e ^ n. Execution of the select proceeds as fol- 
lows: (1) the value of e is computed, (2) the value 
of the expressions €_ . (0 ^ i ^ n) are evaluated, 
(3) for each i such that e = 6, . the expression 
6- - is evaluated. Thus, in tne event that more 
than one value of i exists such that e = G^ • > ^^^h 
of these expressions is evaluated; in this case the 
final value of the select expression is undefined. 



A function call expression has the form 

6(€^,e2,...e^) 

This expression causes activation of the segment 
named by € as a subprogram with an initialization of 
the formal parameters named in the declaration of the 
function to the values of the actual parameters 
€1 >...,€ • Only call-by -value parameters are allowed; 
however, call-by-reference is available since names, 
pointer values, may be passed. The value of a 
function call is that resulting from execution of 
the body of the function. Thus, for example, the 
value of the following block is 3628800. 

begin 

function factorial (n) = 

if .n leg 1 then 1 else .n*factorial(.n-l) ; 
factorial(lO) 
end 



enclosed in brackets triggers a function call. An 
identifier by itself merely denotes a pointer to the 
named segment; thus in the example above Pi, P2 , and 
P3 are the names of functions and thus the value of 
the case statement is the name of one of these 
functions (not the result of executing it). Function 
calls with no parameters are written "€( )". 

The body of any function may be activated as a 
co-routine and/or asynchronous process. An arbitrary 
number of distinct incarnation of a single body are 
allowed. In order to permit any of several realiza- 
tions of co-routine mechanisms only two primitive 
operations are provided. 

create €(€ ,€ ,...,€ ) £t £, length €„ then G 
exchi (€..€(-) ^ ^ "" 

The effect of the create expression is to create an 
independent context (that is, a stack) for the 
function named by € with parameters S-*-, . . . , G"^. The 
stack is set up beginning at the word named by €_ 
and is of size €0 words (to provide overflow protec- 
tion) . The activation record for the newly created 
co-routine is set to the head of the function named 
by G. The value of the create expression is a "pro- 
cess name" for the new co-routine. Control then 
passes on to the expression following the 'create' - 
in particular the expression €, is not executed at 
this time and the body of € is not activated. When 
two or more such contexts have been established, 
control may be passed from the currently executing 
one to any other by executing an exchange jump, 
exch i , expression. An expression "exchj (6 , 6, )" 
will cause control to pass to the co-routine named 
by €c (the value of an earlier create expression) . 
The value €, becomes the value of the exchj opera- 
tion which last cause control to pass out of the 
co-routine named by Gc* 

The familiar "goto. . .label" form of control has 
not been included in Bliss. There are two reasons 
for this: (1) unrestricted goto's require consider- 
able run-time support due to the possibility of 
jumping out of functions and/or blocks, and (2) the 
authors feel strongly that the general goto, because 
of the implied violation of program structure, is a 
major contributor to making programs difficult to 
understand, modify and debug. There are "good" and 
"bad" ways to use a goto and there are restrictions 
which could be imposed which eliminate the need for 
run- time support. Consideration of the nature of 
"good" ways and the restrictions necessary to elim- 
inate run-time overhead led us to eliminate the goto 
altogether, and to the inclusion of conditional, 
looping, and case-select expressions. These alone, 
however, are not sufficiently general, or convenient, 
and consequently the 'escape' expressions were intro- 
duced. There are six forms of escape expressions: 
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EXITBLOCK € 
EXITCOMPOUND 6 
EXITLOOP 6 



EXITCOND e 

EXIT e 

RETURN € 



Note that a function call need not explicitly name a 
function by its associated identifier; all that is 
required is that € evaluate to the name of a segment. 
Thus expressions such as the following are valid and 
useful. 

( case .x of set Pl;P2;P3 tes)(.z) 

Also note that the occurrence of a parameter list 



Each form of escape expression causes control to 
exit from a specified control environment (a block, 
a loop, or a conditional expression, for example) 
and defines a value (€) for that control expression 
(EXIT exits from any form of control expression, 
RETURN exits from a function) . 

Consider a linked list of two word cells, the 
first of which contains a link (pointer) to the next 
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cell (the last cell has link=0) and the second of 
which contains data. The following expression has a 
value which is the pointer to the first negative data 
item, or a value of -1 if no such item is found. The 
address of the head of the list is contained in a 
field called 'head'. 

(register t; t ^ head; while (t ^ .t) neq do if 
. ( . t+1) Iss then break . t) ; 

Note that the initialization of t, i.e., 't ♦- head', 
sets the value of 't' to a pointer to 'head', not 
the contents of 'head'. 

3. Data Structures 

One of the outstanding characteristics of sys- 
tems programs is their concern with the wide variety 
of data structures and schemes for representing 
these structures. Observation of what systems pro- 
grammers do reveals that a very large fraction (near- 
ly 50'^ in our experience) of their design effort is 
spent in designing representations for efficiently 
encoding the information they will process. It is 
frequently the case that the most difficult task in 
making a modification to an existing program is that 
of representing the additional new information re- 
quired (e.g., the infamous "find another bit" prob- 
lem). Consequently the issue of representation was 
one of the central design considerations in Bliss. 

Two principles were followed in the design of 
the data structure facility of Bliss: 

- the user must be able to specify the accessing 
algorithm for elements of a structure, 

- the representational specification and the 
specification of algorithms which operate on 
the represented information must be separated 
in such a way that either can be modified 
without affecting the other. 

The first principle follows simply from the 
fact that non-algorithmic specifications are inade- 
quate to express certain important representational 
schemes. By a non-algorithmic specification we mean 
one which statically specifies the layout of a 
structure in terms of primitive structures (words, 
fields, etc.), other defined structures, and (pos- 
sibly) pointers. By an algorithmic specification we 
mean one which, given a set of parameters (indices) 
computes a pointer to the appropriate structure ele- 
ment. Algorithmic specifications have the advantage 
of generality, but some disadvantage of verbosity 
for simple structures. This latter type of specifi- 
cation will be amply illustrated below. 

In order to achieve a language in terms of 
which it is possible to write large systems that may 
be easily modified, it is imperative that the speci- 
fications of the representation of a data structure 
be separated from the specification of algorithms 
which manipulate data in that structure. This prin- 
ciple is severely violated in assembly languages 
where, typically, the code to access an element of a 
structure, for example, simply a contiguous field of 
bits within a word, is coded "in line" at the point 
where the element is needed. A comparatively triv- 
ial change which alters the size or position of the 
field and may require locating and modifying all 
references to the field. This simple problem could 
be solved by following good coding practice and, 
perhaps, by the use of macros; not all changes are 



of such a trivial nature, however. 

The concept of a "pointer" to a field (of bits 
within a word) was mentioned earlier. Actually in 
Bliss a pointer is a five-tuple consisting of: 
(1) a word address, (2) a field position, (3) a 
field size, (4) an (index) register name, and (5) an 
"indirect address" bit. These five quantities are 
encoded in a single word and as such are a manipu- 
latable item in the language (a prerequisite of 
algorithmic representational specification) . For 
simplicity we shall discuss only the first three of 
these quantities; the reader is referred to the 
Bliss reference manual^ for more detail. The "word 
address", wa, field of a pointer designates the 
physical machine address of the word; the 'posi- 
tion', p, and 'size', s, designate a field within a 
word in terms of the number of bits to the right of 
and within the field. 



word 
"wa-I" 




Ibits tits 



word 
"wa" 



word 
"wa+1" 



word 
"wa+2" 



The notation used in Bliss to specify a pointer 
(taking only the simple wa,p,s case) is "wa<p,6>". 

Assume that the declaration 

own x[100] 

has been made. The identifier x is bound by this 
declaration to a pointer to the 36 bit field which 
is the first word of this 100 word segment. That 
is, the word address of the pointer "x" is that of 
the location allocated to the segment and the posi- 
tion and size fields have values of zero and thirty- 
six respectively. If we denote the address of the 
segment by a , then an occurrence of "x" in a Bliss 
program is identical to an occurrence of "a <0,36>". 
If €q - €2 are expressions, then the syntactic form 

is by definition a pointer whose word address is the 
value of €q (modulo 2^°) and whose position and size 
specifications are the values of €1 and £, (modulo 
2°) respectively. Thus "X<3 ,4>" is a pointer to a 
four bit field three bits from the right end of a 
word named X. The word address, position, and size 
information are encoded within a pointer in such a 
way that adding small integers (<2^°) to a pointer 
increments the word address only. Thus "X+1" is a 
pointer to the word following X. 

The definition of a class of structures, that 
is, of an accessing algorithm to be associated with 
certain specific data structures, is made by a dec- 
laration of the form: 

structure <name> [<f ormal parameter list>] = € 

Particular names may then be associated with an 
accessing algorithm by another declaration 

map <name>:<name list> 
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Consider the fol loving example: 



current structure declaration for "ary2" by 



begin 

structure ary2[i,j] » (.ary2+(.i-l)*10+(. j-1)) ; 
own x[100],y[100],2[100]; 
ma£ ary2: x,y,z; 

x[.a,.b] *- .y[.b,.a]; 



end ; 

In this example we introduce a very simple structure, 
ary2, for two dimensional (10x10) arrays, declare 
three segments with names 'x' , 'y' , and 'z' bound to 
them, and associate the structure class ary2 with 
these names. The syntactic forms "xLCi.Gjl" and 
"yC^^.C, ]" are valid within this block ana denote 
evaluation of the accessing algorithm defined by the 
structure declaration (with an appropriate substitu- 
tion of actual for formal parameters) . Within the 
expression defining a structure class, the name of 
the structure class, ary2 in this case, denotes the 
name of the "zeroth" formal parameter - and is re- 
placed by the name preceding the "[" at the call 
site. Thus, ".ary2" denotes the value of the name 
of the particular segment being referenced. In the 
example 'x[.a,.b]' is equivalent to: 

(x+(.a-l)*10+(.b-l)) 

The value of this expression is a pointer to the 
designated element of the segment. 

In the following example the structure facility 
and bind declaration have been used to efficiently 
encode a matrix product 
10 
(z, . = 2 x.,y, .). 



i-O 



= 1 ik-'kj' 



k=l 



In the inner block the names 'xr' and 'yc' are 
bound to pointers to the base of a specified row of 
X and column of y respectively. These identifiers 
are then associated with structure classes which 
allow one-dimensional access. 

begin 

structure ary2[i,j] = (.ary2+(. i-l)*10+(. j-1) ) , 

row[i] = (.row+.i-l), 

col[j] = (.col+(.j-l)*10); 
own x[100],y[100],z[100]; 
map ary2 : x,y,z; 

incr i from 1 to 10 do 

begin bind xTi»x[.i. 1] ,zr=2 [.i,l]; map row:xr,zr; 
incr j from 1 to 10 do 
begin 

register t; bind yc=y [1, . j ];ma£ col:yc; 

t ♦- 0; 

incr k from 1 to do t <- .t+.xr [.k]*.yc[.k] ; 

z[.j] ^ .t; 

end; 
end; 



end 



Suppose now that one wishes to alter the repre- 
sentation of the structure 'ary2', and access to the 
array is to be made through an Ilife vector (or, 
"dope" vector) to define the relative base of each 
row. The major change required is to replace the 



own il[10]; map row: il; 

structure ary 2 [i,j ] = ( .ary2+. il [.i-l]+. j-1) ; 

With this representation, the use of a special ac- 
cessing algorithm (structure) for accessing columns 
becomes 

structure col[j] = (.col + .il[.j-l]); 

As can be seen, these fairly simple changes to the 
program completely changes its representation of the 
data. No changes to the processing algorithm are 
required. 

4. Miscellaneous Features 

Finally, we shall now describe two features of 
the language which are important to the goal of 
parameterization of programs. The first is simply 
that constant expressions are evaluated at compile 
time. This is a common feature of compilers and not 
particularly exciting by itself. Note, however, 
that since the value '1' is interpreted as true, and 
'0' as false, expressions such as 



if 1 and 1 or then 



else 



are constant in that only the then part will be 
executed. The compiler notes this and does not 
emit the code for testing the condition or evaluat- 
ing the else part. Similarly, only the third ex- 
pression of the following case expression will be 
evaluated at execution time, and consequently the 
compiler only generates code for that expression. 



case -1+2+1 of set €, 



— ^^^ ^C "1' 



tes; 



The second feature is a fairly elementary 
string replacement macro capability. A macro name 
and its associated text are introduced by a declara- 
tion of the form: 



ntapes = 3$, 
ndrijms = 5$, 
loop(i,n) = incr i from 1 to n do $; 



This particular declaration defines three macro 
names ('ntapes', 'ndrums', and 'loop') and defines 
a text string which is to replace the macro name 
(and its parameters, if any) where it (they) is 
(are) mentioned in the scope of the declaration. 
The end of a text string is delimited by '$', and 
may mention formal parameter names - these are re- 
placed by actual parameter strings used at the call 
site. 

One may combine these two features to para- 
meterize a system. Consider the following skeletal 
code: 



begin 
macro 



own 
structure 



map 



ntapes = 3$, 

ndrums = 5$, 

descsize = 2$, 

cloop(i,n) = if^ n gtr then incr i 

from 1 to n do $; 
devicedesc [ntapes*ndrums*descsize] ; 
devary [i,j] = (.devary + (.i-l)*desc- 

size + . j); 
devary: devicedesc; 



3 



3 







1-6 



The declarations above define a table of device 
descriptions for magnetic tapes and drums. The num- 
ber of entries for tapes and drums, and the number 
of words per description entry are controlled by the 
macro definitions 'ntapes', 'ndrums', and 'descsize'. 
Suppose the number and size of fields within the 
device description for tapes and drioms are differ- 
ent. The following structure and bind declarations 
allow one to access these fields conveniently: 

structure tapeary [i,j] = 
case (.j-1) of 
set 



( . tapeary + 
( . tapeary + 
( . tapeary + 
tes ; 

structure drumary 
case (.j-1) of 
set 

(.drumary + 
( . drumary + 
(.drianary + 
( . drumary + 
(.drumary + 
tes ; 

bind tapedesc 
drumdesc 

map tapeary: 



(.l-l)*descsize)<0,36>; 

(.i-l)*descsize)<18,18>; 

(.i-l)*descsize)<18,18>; 

[i,j] = 



(.i-l)*descslze)<0,36>; 
(.i-l)*descsize+l)<18,18>; 
(.i-l)*descsize+l)<17,l>; 
(.i-l)*descsize+l)<16,l>; 
( . i-l)*descsize+l)<0 , 16>; 

= devicedesc [0,0], 

= devicedesc [ntapes,0]; 

tapedesc, drumary: drxjmdesc; 



These declarations make it feasible for the 
programmer to refer to 'tapedesc [.1,2]', for 
example, as the second field of the description of 
the 1 th tape without regard to the size or location 
of that field. The following code uses the constant 
expression evaluation feature to selectively Include 
only relevant code. 

global function initialize = 
begin 

cloop(l, ntapes) 
begin 

^code to initialize tape description goes 
here^ 
end; 
c 1 oop ( 1 , ndrums ) 
begin 

% code to initialize drum descriptions goes 
here '^ 
end ; 
4> other initialization code goes here 'fo 
end; 
if ntapes gtr then 
begin 

global function tapehandler = 
begin 

'^ code for body of tape device handler ^ 
end; 
global function tapeopen = 
begin 

Jo code for special file-open actions on 
magnetic tape '^ 
end ; 
^ other specialized tape functions declared 
here <% 
end 

Since the body of an "if €, then €2" expression is 
not compiled in the case that the t, is a constant, 
and false, the global functions 'tapehandler', etc., 
are not compiled unless 'ntapes' is greater than 
zero. One can imagine more complex expressions, 
such as 'if^ (ndrums gtr 0) or (ndisks gtr 0) then ' , 



controlling the inclusion of, for example, file- 
directory handling code. 

EVALUATION AND CONCLUSIONS 

As of this writing the Bliss compiler is in its 
final stages of completion, and consequently experi- 
ence using the language is somewhat limited. To 
date only one major project has been undertaken in 
Bliss, namely the compiler itself. The language 
has evolved as a consequence of this experience, and 
we expect it will evolve further as it is used. 

In spite of the relative lack of experience in 
using the language, it would be very nice to have 
some objective measures of the language - measures 
of such things as efficiency, appropriateness (to 
the systems programming problem) , readability, con- 
sistency, etc. Such measures are, of course, very 
difficult to define objectively. However, we have 
attempted to supply some data from which the user 
may draw his own conclusions. One of these data 
points indicates the quality of code produced by the 
Bliss compiler - and is therefore an indirect mea- 
sure of the suitability of the language for one 
system's programming problem. The second bit of 
data is an annoted table comparing features of some 
implementation languages. 

The measure chosen for code quality of the 
Bliss compiler is simply that of code size. Three 
sections of the compiler were chosen as a basis for 
comparison in an attempt to factor out those things 
which (1) are intrinsic to the structure of the 
language, (2) are a function of the current optimiza- 
tion strategies of the compiler (which can always be 
improved) , and (3) are a function of a particular 
programmer's "style". The sections are named 10, 
LEXAN, and SYNTAX and are respectively the l/o 
Interface, lexical analyzer (symbol table routines, 
etc.), and syntax analyzer. Of these, 10 was orig- 
inally written in "clever" assembly code and later 
translated into Bliss, while LEXAN and SYNTAX were 
originally written in Bliss and then translated by 
hand into assembly code. The translation of LEXAN 
was done in such a way as to mirror the functional 
structure of the original Bliss code at the sub- 
routine level but Internally was coded for maximal 
efficiency. SYNTAX, on the other hand, was trans- 
lated with the aid of a number of general purpose 
macros and mirrors exactly the structure of the 
original Bliss text. The results are as follows: 



10 

LEXAN 
SYNTAX 



approximate 
size 



relative size of 
compiled version 



50 
1300 
2300 



40% larger 

74 larger 

20"^ smaller 



From this small sample one can draw some tentative 
conclusions: 

1. 10 is something like a worst case. It is 
small (which tends to exaggerate the over- 
head for recursion, etc.) and it was orig- 
inally written in assembly code. The pen- 
ality in such a case appears to be on the 
order of 50^. 

2. Since the hand coding of LEXAN obeys the 
subroutine calling conventions of compiled 
Bliss programs, but is otherwise coded 
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fairly tightly - the penality for the current 
optimization techniques appears to be on the 
order of lO^^o. 

3. The compiler does considerably better than 
macro extension of assembly code. 

Table I and its associated notes compare certain 
features of implementation languages as described by 
the most recent documentation available to these 
authors, and speaks for itself. Neither the list of 
features nor the list of languages is exhaustive; 
both reflect the prejudcies of the authors. Nvimbers 
in the lower right corner of entries refer to the 
notes following the table. 

The comparisons of code size and language fea- 
tures given above hopefully provide some insight 
into the use of Bliss as an implementation tool; 
unfortunately, they do not give absolute measures of 
its utility. In particular there seems to be no way 
at present to measure the benefits of maintainability 
and modifyability - and these are, in the opinion of 
the authors, its major advantage. 

NOTES ON TABLE I 

1. Of course no language is explicitly designed to 
produce large, slow programs. The entries in 
this row reflect the extent to which efficiency 
was a prime goal and the extent to which con- 
cessions were made. 

2. Bliss and Espol have limited macro facilities 
when compared to most macro assemblers, namely, 
simple string replacement (with parameters). 
PL/i has extensive macro facilities, but these 
are not described as part of EPL. 

3. All of the languages listed either have the 
ability to embed assembly code or to call machine 
language subroutines. The entry relater- princi- 
pally to the former facility. 

4. The entries are coded as follows: 

M machine data types 
C conceptual data types 
op type interpretation is derived from 
operator 

V type interpretation is derived from 
variables 

D type interpretation is derived from data 

5. 'na' denotes 'not applicable'. 

6. Fortran, Espol and EPL provide no control over 
the representation of data structures. Macro, 
BCPL, SAL, and PL/360 provide such control; how- 
ever the access to elements of structures must 
be programmed "in-line". 

7. Macro, SAL, and PL/360 permit recursions in the 
sense that the programmer may choose to explic- 
itly code a recursive calling sequence. 

8. The following code are used to denote various 
parameter passing options. 

V call -by-value 
N call -by -name 

R call-by-reference 



9. The following codes are used to denote various 
control statement forms: 

I- Fortran if -statement 

l^ Algol-like "if-then-else" 

D Do -statement 

F Algol-like for-statement 

C case statement 

SF simple-for (corresponds to Algol step- 

until case) 
W while-statement 
G goto 
SO BCPL "switchon", similar to Bliss 

"select" 
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TABLE I 
COMPARISON OF IMPLEMENTATION LANGUAGES 



c 



GOAL 
FEATURE 



space/ time 
economy 



A 



machine 



independence / 



Macro 



access to 
hardware 



A 



run time support 
required 



r 



data types 



A 



automatic con- 
version of data J 
types ^ 



data structures 



Z 



control of repre- 
sentation of 

atmcturcs 



/ 



recursion 



1 



CO -routines 



A 



parameters 



A 



conditional/ y 
looping, etc. /g 



References 



BLISS MACRG-10 



goal 



no 



Z 



yes 



i 



yes 



I 



1 



M,op 



/ 



1 



user 
defined 



i 



yes 



/ 



yes 



L 



yes 



L 



V,R 



A 



see 
text 



[6] 



FORTRAN 



goal 



A 



yes 



1 



yes 



A 



M,op 



A. 



Z. 



user 
lefined 



L 



yes 



L 



yes 



A 



yes 



I 



na 



I 



[7] 



goal 



A. 



yes 



no 



1 



I 



yes 



L 



c,v 

real , / 
ntegerV 



yes 



I 



arrays 



I 



no 



1 



no 



Z 



z 



1 



/ na / Iq,D,G /I^,F,C,G/' 



B5500 
ESPOL 



goal 



A 



yes 



yes 



Z 



1 



EPL 

(pl/i) 



yes 



yes 



Z 



yes 



z 



arrays 



hler- 
/archical/ 



no 



/ 



yes 



Z 



V,N,R 



/ 



[2] 



yes 



Z 



Z 



yes 



z 



/ 



V,R 



I 



Il.D,Gy 



[1] 



BCPL 



yes 



M,op 



Z: 



,re4l, 



Z 



vectors 



^ 



yes 



Z 



yes 



Z 



v,R 



[4] 



SAL PL/360 



goal 



z 



z 



yes 



1 



1 



.real, > 
IntegeA/ 



na 



z 



user 
defined 



'I 



yes 



Z 



ZJI^ 



z 



V.R 



Z^ 



I,,SF,W, 
C,SO,Gy^IySF,W,^ 



[8] 



goal 



yes 



Z 



no 



user 
defined 



'L 



yes 



Z 



yes 



i 



V,R 



z 



I,,SF,W, 



[3] 
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SECTION VI 
BLISS EXAMPLES 

This section contains a set of examples which illustrate the use 
of Bliss. Each example is intended to be fairly complete and self con- 
tained, and to illustrate one or more features of the language. 

The authors would like to invite others to contribute further ex- 
amples for inclusion in this section. New examples will be included 
if they clearly illustrate features and/or uses* of the language which 
are not already adequately illustrated. 
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EXAMPLE 1: A TT-CALL l/o PACKAGE 
Contributors: C. Geschke and W, Wulf 

The follov7ing set of declarations defines a set of teletype input/ 
output routines using the PDP-10 monitor TT-call mechanism. The set of 
functions is not complete, but adequate to illustrate the approach. 

The declarations below provide the following functions: 



D 



INC Input one character - wait for EOL before returning 

OUTC Output one character 

OUTSA Output ASClZ-type string beginning at specified address 

OUTS Output ASCIZ-type string specified as the parameter 

OUTM Output multiple copies of a specified character 

CR Output carriage return 

LF Output line feed 

t 

NULL Output null character 

CRLF Output carriage return and line-feed followed by 2 nulls 

TAB Output tab 

OUTN Output number in specified base and minimum number of digits 

OUTD Output decimal number with at least one digit 

OUTO Output octal number with at least one digit 

OUTDR Output decimal number with at least specified number of digits 

OUTOR Same as OUTDR except octal 



3 



D 



2-2 



M)DULE TTIO(STACK)«BEGIN 

MACHO P TTCALLa#51i 

MACRO INCa CREGISTER Q; TTCALL<4,Q); •Q)$, 

OUTCCZ)« (REGISTER Q; Q-CZ); TTCALLC 1,Q) ) S, 

OUTSA<Z)» TTCALL<3*Z)$, 

OUTS(Z)» OUTSA(PLIT ASCIZ Z)S, 

OUTMCC#N)» DECR I FROM (N>-1 TO DO OUTCCOS* 

CR» 0UTC<#15)$, LFa 0UTCC#12)$, NULLe OUTC<0)$* 

CRLi"= OUTSC 'TM? J?0?0')$, 

TAB= 0UTC<#11)$; 



ROUTINE OUTN(NUM,BASE>REQD)= 
BEGIN OWN N*B>RD*T5 
ROUTINE XN» 

BEGIN LOCAL R; 

IF .N EQL THEN RETURN OUTMC "0»% .RD-. T)5 
R-»N MOD .B; N-.N/.B; T-.T+i; XNOl 
OUTCCR*"©") 

end; 

if •num lss then outcc"-"); 
b^*base; rd*-.reqd; t-o; n-abs<«num); xno 
end; 



^-^ MACRO OUTD<Z)a OUTNCZ#lO*l)$# 

OUTO(Z)a 0UTN(Z*8*1>S# 
OUTDRCZ>N>= 0UTN(Z*10*N)$> 
0UT0R<Z#N>a 0UTN<Z>8*N)$; 

I THE PROGRAM BELOVI PRINTS A TABLE OF INTEGERS* THEIR SQUARES* AND 

f THEIR CUBES: 

OWN N*c; 

CRLF; OUTSC 'INPUT AN INTEGER PLEASE .♦••>; 

N-O; WHILE (C*-INC) 6TR "O" AND .C LSS ••9" DO N- .N*10+C • C-"0"); 

CRLF; OUTSC 'A TABLE OF THE SQUARES AND CUBES OF !-•); OUTD<«N>; 

CRLF; INCR I FROM 1 TO 3 DO CTAB; OUTSC' Xt»); OUTDC.D); 

CRLF; INCR I FROM 1 TO 3 DO CTAB; OUTMC"-*S 5) >; 

INCR I FROM I TO .N DO 
BEGIN OWN X; 

x-«i; crlf; 

/-^ DECR J FROM 2 TO DO CTAB; OUTDCX); X*-.X*.I) 

O END 

END ELUDOM 

2-3 



Although the example is quite simple, there are several things about 
it which should be noted: 

1. The use of a MACHOP declaration and embedded assembly code. 

2. The use of macros to add a level of "syntactic sugar" and 
general cleanliness to the code. 

3. The use of the escape character "?" in the CRLF macro to 
obtain control characters (e.g., carriage-return) in strings. 

4. Parenthesisation of macro parameters, as in OUTM, to insure 
proper hierarchy relations in the expansion. 

5. The use of "DECR-TO-ZERO" in OUTM because it produces better 
code than "INCR-TO -EXPRESS ION". 

6. The use of ov'/n variables and the parameterless procedure XN 

in OUTN in order to avoid passing redundant parameters through 
the recursive levels of XN, 

7. The fact that the local variable "R" is local to each recursive 
level of XN and hence its value is preserved at each level. 
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EXAMPLE 2: QUEUE MANAGEMENT MODEL 
Contributors: C. Geschke and W. Wulf 

This module contains routines to insert and delete items on doubly- 
linked queues. In addition it contains space management routines imple- 
menting the "Buddy System" (cf: Knuth: Vol. 1). 

Buddy System 

This is not intended to be a detailed description of the buddy system 
model of space management. We will simply give a brief description of 
this implementation of the scheme. The vector of allocatable space is 
called MEM, Space is allocated and deallocated from KM by the routines 
GET and RELEASE, respectively. The basic unit of allocatable space is an 
item. Items are of size 2**ITEMSIZE where < ITEMSIZE ^ L0G2MEMSIZE. 
The first two words of an item are formatted: 



ITEMSIZE 


RLINK 


<NOT-USEI)> 


LLINK 



Available items of size N are elements of a doubly linked list whose 
header is the two word cell SPACE[N]. The routines LINK and DELINK are 
called to enter and remove items from lists. The routine COLLAPSE is 
used to compactify two adjacent available items of size 2**N into an item 
of size 2**(N+1). The COLLAPSE routine iterates this process until no 
more compactification can take place. 



2-5 



fflieue Model 

In this model a queue is defined to be a doubly-linked list suspended 
from a header whose first three words are formatted as follows: 



J 



HEADERSIZE 


RLINK 


<NOT-USED> 


LLINK 


REMOVE 


ENTER 



The fields REMOVE and ENTER contain the addresses of the routines to 
be invoked when removing and entering items on the queue. To enter item X 
on queue Q, one simply makes the call ENQ(X,Q). ENQ then invokes the 
enter routine in Q's header which returns the address of the item in Q 
after which X is to be inserted. In a similar manner one removes the 
"next" item from queue Q bv the call DEQ(Q). DEQ then invokes the remove 
routine in Q's header to return the address of the "next" item. The ad- 
vantage of this scheme is that the queueing discipline is queue specific, 
and the same primitives (ENQ and DEQ) may be used independent of the 
discipline used for that queue. Examples of the enter and remove routines 
for LIFO, FIFO, and PRIORITY type queues appear at the end of this example 
module. 
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M3DULE QMS (STACK >• 

I BUDDY SYSTEM 
I 

B£Gm 

BIND MEMSIZE«lt 12; 

GLOBAL VECTOR MEMCMEMSIZE3; 

BIND L0G2MEMSIZEa35-FIRST0NE(MEMSIZE>; 

STRUCTURE ITEMC I# J*P*S3« 
CASE •! OF 
SET 

C.ITEM)<«P,.S>; 
<•• ITEM*. J)<.P,.S>; 
C f #• ITEM4-« J)<« P# • S> J 
<§C«.ITEM-i-l>+. J)<.P#,S> 
TES; 

STRUCTURE VECT0R2CI3a 

C2*I 3< • VECT0R2+2*. I )<0# 36>; 

MACRO BASEs0> 0^0« 18S« 
RLINK»U0#0#18$> 
LLINK»1>U0#18$# 
ITEMSIZEaU0>28#18$> 
NXTRLINKb2#0«0#18S> 
NXTLLINKb2>1#0«18S« 
PRVRLINk-3* 0# 0> I 8$# 
PRVLLINK>i3> U0> 18$i 

GLOBAL VECT0R2 SPACECLOG2MEMSIZE-M3I 

BIND VECTOR SIZE « 

PLIT<ltO#ltl,lt2, It3*lt4, It5#lt6#lt7#lf8*lt9#ltl0* 
ltU«ltl2>; 

MACRO PARTNER<Bl#B2*S)a ( ( <CB1 )-MEM<0#0>) XOB <<B2)-MEM<0*0>) ) 

EQL •SIZECS3>S^ 
REPEATa WHILE 1 DOS* 

BASEADDR(B*S)« MEMC C <B)-MEM<0*0> > AND NOT .SIZECS33<0# 0>$* 
ERRMSGCS)« ERROR(PLIT ASCIZ S)$; 
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f SPACE-MAMAGEMEMT-ROUTINES D 

t 

FORWARD EMPTY*ERROR*LINK,DELIWK* collapse; 

GLOBAL ROUTINE GET(N)a 

IRETURNS THE ADDRESS OF AN ITEM OF SIZE 2**N 

BEGIN REGISTER ITEM R; 

IF .N LEQ OR .N GTR L0G2MEMSIZE 

THEN ERRMSGC 'INVALID SPACE REQM; 
IF NOT EMPTY<SPACEC.N3<0#0>) 

THEN RCBASE3-DELINK(.SPACEC.N3> 
ELSE 
BEGIN 

RCBASEa-GETC.N-i-l); 

collapse<.rcbase3*.sizec«n3*«n) 
end; 
rcitemsize>.n; 

•RCBASE3 

end; 

routine collapse(a,n)« ^ 

! called by release and get to attempt to compactify space 
! i f adjacent i tems are free 

BEGIN MAP ITEM A; REGISTER ITEM L; 
REPEAT 
BEGIN 

LCBASE]«-SPACEC.ND<0*0>; 
WHILE •LCRLINK3 NEQ SPACEC-N3<0* 0> DO 
IF PARTNER(.LCRLINK3#«ACBASE3#.N) 
THEN 
BEGIN 

ACBASE3-BASEADDR(DELINK<.LCRLINK3)*.N); 
N*-.N+i; 

EXITC0MP0UNDC2] 
END 

else lcbase3-.lcrlink3; 
return cacitemsize3-.n; linkc . acbase3#.lcbase3 > ) 
end; 
end; 

global routine release(a)» 

i called to release item a 

BEGIN "^ 

MAP ITEM a; -^ 

collapse(«acbase3>.acitemsize3) 
end; 
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! SIMPLE-LIST-ROUTINES 
! . 

HDUTINE DELINK(A)a 

iremoves item a from the list to which it is appended 

begin map item a; 

acprvrlink3-.acrlink3; acnxtllink3-. acllink3; 

acrlimk3-acllink3-.acbase3 
end; 

routine link(a*too)« 

! inserts item a into a list immediately after the item too 

BEGIN 

MAP ITEM A:T00; 

acllink3-.toocbase3; acrlink3-. t00crlink3; 
toocnxtllink3-toocrlink3-.acbase3 
end; 

routine relink(a#too)« 

! removes item from its present list and inserts it after too 
link(delinkc.a>*«too); 

routine emptycl)« 

ipredicate indicating empty list 

BEGIN MAP ITEM L; 

.lcbase3 eql .lcrlink3 
end; 
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I QUEUE-HAMDLIWG-ROUTINES -^ 

» O 

MACRO QHDR« items; 

MACRO ENTER=1,2>0> 18$* 

REM0VE=l*2>18#18$; 

GLOBAL ROUTINE ENQ(A,Q> = 

! ENTERS ITEM A ON QUEUE Q ACCORDING TO THE INSERTION DISCIPLINE 
! EVOKED BY Q'S ENTER ROUTINE 

BEGIN 

MAP QHDR Q; 

relink(.a*<.qcenter3)<.qcbase3>.a>> 
end; 

global routine deq<q)=» 

! removes an item from queue q according to the removal discipline 
! evoked by q»s remove routine 

BEGIN 

MAP QHDR Q; ^ 

delinkc ( ♦ qc removed ) c . qcbased ) ) ^ 

end; 

i misc service routines 

I 



ROUTINE ERROR(A)» 

BEGIN MACHO P TTCALL=#05i; 
TTCALL(3*.A) 

end; 



ROUTINE INITIALIZE* 

UNITIALIZES THE SPACE MANAGEMENT DATA 



begin register item x; 
xcbase3-mem<o*o>; 

XCRLINK>XCLLINK3^SPACECLOG2MEMSIZE3<0#0>; 

XCITEMSIZE3-L0G2MEMSIZE; 

DECR I FROM L0G2MEMSIZE-1 TO DO 

SPACEC • I 3*- C SPACEC . I 3 + 1 )<0# 36>-SPACEC . I 3<0* 0>; 
SPACECL0G2MEMSIZE3-<SPACECL0G2MEMSIZE3 + n<0#36>-MEM<0>0> ^ 

end; ^ 
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! EXAMPLES OF VARIOUS QUEUE MODELS 
J- 

f LIPO QUEUE 
! 

ROUTINE LIFOREMOVE<Q)s 
BEGIN 

MAP QHDR Q; 

IF EMPTY<«QCBASE3) THEN 

ERRMSGC 'INVALID DEQ REQUEST'); 
•QCRLINK3 

end; 



HDUTINE LIFOENTER(Q>A) 
BEGIN 

MAP QHDR Q; 
•QCBASE3 

end; 



! FIFO QUEUE 
I 



ROUTINE FIFOREMOVECQ)- 
BEGIN 

MAP QHDR Q; 

IF EMPTY<.QCBASE3) THEN 

ERRMSGC 'INVALID DEQ REQUEST'); 
.QCRLINK3 

end; 



ROUTINE FIP0ENTER(Q#A) 
BEGIN 

MAP QHDR Q; 
.QCLLINK3 

end; 
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! PRIORITY QUEUE 
I 



MACRO PRI0RITYaUl>18#18S; 

ROUTINE PRIREMOVE<Q)a 
BEGIN 

MAP QHDR Q; 

IF EMPTY(.QCBASE3) THEN 

ERRMSG( 'INVALID DEQ REQUEST*); 
.QCRLINK3 

end; 
fdutine prienter(q#a)- 

BEGIN 

MAP QHDR Q; map ITEM A; REGISTER ITEM Li 

IF EMPTYC.QCBASE3) THEN RETURN .QCBASE3; 

LCBASE3-.QCLLINK3; 

UNTIL .LCPRI0RITY3 GEQ .ACPRIORITY] DO 

LCBASE3-»LCLLINK3; 
•LCBASE3 

end; ^ 

END ELUDOM 
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Comments on the Use of Bliss In the Implementation 

(1) The structure ITEM is particularly interesting and perhaps at 
first a bit obscure. 

To illustrate, consider a variable X structured by item: 

Assuming that the right half of X contains q?: 



and that: 



.^Y: 





a — 




Tl 




Then: 



.X[BASE] = Of 
,X[RLINK] = P 
.X[LLINK] s Y 



.X[NXTRLINK] 
.X[NXTLLINK] 
.X[PRVRLINK] 
.X[PRVLLINK] 



6 
a 
a 



The structure ITEM uses the "constant case" expression to distinguish 
between the pointer, the pointee, and the pointee's predecessor and successor. 

(2) The structure VECT0R2 has a size expression [2*1] which is used 
in the allocating declaration: 
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GLOBAL VECT0R2 SPACE [L0G2MEMS IZE+1 ] ; ^ 

(3) Since the addresses of the 'remove' and 'enter' routines are 
stored in the queue header, the expression 

(.Q[REMOVE])(.Q[BASE]) 

is a call of the routine whose address is .Q[REMOVE] and passes it to 
the base address of the queue or its parameter. 

(4) The macro 'REPEAT = WHILE 1 DO' defines an infinite loop - 
its only exit is defined by the RETURN expression in its body. 

(5) Notice the 'BIND VECTOR SIZE = PLIT(ltO,ltl,lt2, . . . ' in the 

space allocator. The value of SIZE is a pointer to this sequence of 

N -^ 

values, and in particular the value of '.SIZE[.N]' is 2 . ) 
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EXAMPLE 3: DISCRIMINATION NET 
Contributor: D. Wile 

A discrimination net is a mechanism used to associate "information" 
with "names". The net is actually a tree, each node of which consists 
of a name and the information associated with that name, as well as a 
set of pointers to other nodes. To look up a name in the net we start 
at the root node and see if the name in the node matches our target name. 
If it does, we return the associated information. 

Otherwise, we use a "discrimination function" which determines 
which subnode to examine next (usually as a function of the target name 
and the name of the current node). If there is no corresponding subnode, 
a new node must be created. 

For example, a binary net (two subnodes/node) with a discrimination 
function which chooses the left branch if the target name is alphabetically 
smaller than the name in the node, is illustrated below: 

Name: j, 9, 1, a, b, r, p, n, s, k 
Inf: 4, 7, 9, 8, 5, 20,3, 9, 7, 12 




n:9 
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In the implementation which follows, there are three globally defined ^ 
routines: 

1. DSCINIT (String address) -- returns a pointer to the in- 
formation field of the node associated with the string. 
This must be called first to initialize the net. (Tlrie 
information field will be zeroed when the node is new, ) 

2. DSCLKP (String address) -- the "lookup" routine. Value 

«, 
returned as above, 

3. DSCPNAME (Information field address) -- returns a pointer 
to the print name associated vjith the particular informa- 
tion field. 



The implementation is designed to allow the user to creaie a module some- 
what "tailored" to his needs. The module is created by passing: 

1, the estimated number of entries to be inserted into the table; 

2, the average number of words each name will occupy; 

3, the number of words in the "information field"; 

4, the number of subnodes of each node (e.g,, binary example 
above, 2); 

5, a string which executes an error routine 

in that order, to a macro "DSCRIMINET", Two macros must be defined 
previous to the DSCRIMINET expansion: 



D 



D 



2-16 



1. DSCIMINATE (Target string address, current node string 
address) must have a value of -1 if the strings match. 
Otherwise, its value must be between and 1 less than 
the number of subnodes. 

2. DSCCOPY (To address, From address) copies the string from 
the "from address" to the "to address", returning the 
number of words occupied by the copy. 
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M)DULE NET<STACK=GL0BAL(STABK*#400))« 

BEGIN -> 

MACRO ^ 

DSCRIMINET(MAXNUMENT*AVNAMESI2E#INFSIZE*N0SUBN0DES#ERR0R>« 

BEGIN 

XN.B. : ALL VECTOR ACCESSES ARE INDIRECT THROUGH THE BASEX 
STRUCTURE VECT0RCI3-< ».VECTOR-f . I ><0#36>1 

% NET SPACE ALLOCATION* STRUCTURE DEFINITION AND 

INITIALIZATION DEFINITIONS X 
BIND TABLELENaMAXNUMENT*<<NOSUBNODES+l )/2-MNFSIZE+AVNAMESIZE); 
OWN BASEN0DECTABLELEN3; 

, BIND maxadd=basenode+tablelen; 

BIND SUBNODEsO* INF=1> PNAME»2# 
INFOFFSET=<NOSUBNODES+1>/2# 
PNAMEOFFSETalNPOFFSET-HNFSIZEi 

STRUCTURE NODECSUBFIELD, INDEXD^CASE .SUBFIELD OF 
SET .N0DEC«INDEXt(-l)3<IF .INDEX THEN 18*18>; 
• N0DECINF0FFSET3J 
.N0DECPNAME0FFSET3 TES; 
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GLOBAL ROUTINE DSCPNAME( INFPOS)« 
(•INFPOS-HNFSIZE)<0#36>1 

OVN NODE NEXTCELLJ 

ROUTINE INITNODE(CELL#STRING)a 
BEGIN 

DECR I FROM PNAMEOFFSET-1 TO DO CELLC.I3-0i 
IF MAXADD LEQ (NEXTCELL*- .NEXTCELL-I-PNAMEOFFSET+ 
(MAP NODE cell; DSCCOPYC CELLCPNAME3*. STRING) ) ) 

then error else .cell 
end; 

global routine dscinitcstring)- 

BEGIN 

LOCAL NODE RETVAL; 
NEXTCELL- BASENO DE; 

retval- initnode(basenode*. string); 
retval cinf3 
end; 

ROUTINE NEVCELLCSTRING)«INITN0DEC.NEXTCELL*. STRING); 

X THE LOOKUP ROUTINE ITSELF X 
GLOBAL ROUTINE DSCLKPCSTRING)- 
BEGIN 

LOCAL DISCIND> NODE CURRENT I NEXT; 

NEXT- BASENO DE; ^ 
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DO 

BEGIN 

CURRENT-. next; 

IF <DISCINI>DSCIMINATEC.STRING>CURRENTCPNAME3)> LSS 
THEN RETURN CURRENTCINF3; 

NEXT-.CURRENTCSUBN0DE*.DISCIND3 
END 

until .next eql oj 

next-currentcsubn0de#.discind3-newce: l(. string); 
nextcinf3 
end; 
end;$; 



ROUTINE DSCIMINATE<L>R)= 
BEGIN 

STRUCTURE VECT0RCI3«( §. VECTOR+. I ><0*36>; 
INCH I FROM 
DO BEGIN 

BIND LEFTa*LC.I3* RIGHT=.RC» I 3; 

IF LEFT NEQ RIGHT THEN EXITLOOP <LEFT LSS RIGHT); 
IF (LEFT AND #376) EQL THEN EXITLOOP -1 
END 

end; 
routine dsccopyc into # fro )« 

BEGIN 

STRUCTURE VECTORC I 3aC #. VECTOR*. I)<0*36>; 
INCH I FROM DO 

IF <CINTOC.I3-.FROC.I3) AND #376) EQL 
THEN EXITLOOP .I-^l 

end; 

EXTERNAL ERROR; 

DSCRIMINET<500#3#l#2^ERR0R<PLIT 'LOOKUP TABLE OVERFLOW')) 

BEGIN 

BIND NAMES=PLITC 

PLIT ASCI2 'FIRSTNAME'* 

PLIT ASCIZ 'SECOND'* 

PLIT ASCIZ 'SS'* 

PLIT ASCIZ 'A LONGISH NAME'* 

PLIT ASCIZ 'L'* 

PLIT ASCIZ '77788034'); 

EXTERNAL DSCLKP* DSCINIT; 

dscinit<plit 'zeroth name')--3; 

incr i from to .namesc-13-1 do dsclkpc.namesc 1 3 )-• i; 

inch i from to .namesc-13-l by 2 do dsclkpc .namesc 1 3 )-• i + u 35; 
end; 
END eludom;; 
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Notes on the Implementation "^ 

The Bliss module above implements the example described at the be- 
ginning of this section. The test program portion of the module simply 
initializes the table, inserts the six strings in the plit into the 
table (associating as information, the index in the plit) , and runs 
through the evenly indexed items in the plit, turning on the sign bit in 
the information word. 
Of interest: 

1. The vector structure (which defaults as the structure 

for all unmapped variables and expressions) is redefined 
"indirectly"; this is fairly dangerous in any program, 
and represents an after-the-fact programming decision. 



2. The physical structure of the table is kept independent 
of the logical structure as used by the lookup routine; 

no reference is made from the lookup routine to the struc- 
ture other than through the structured nodes. 

3. The binds, structures, own declarations and even the 
initialization function - requiring knowledge of the 
physical structure are kept grouped and separate. Note, 
for example, that INITNODE uses both a vector mapping on 
contiguous fields of CELL and the NODE structure. 

4. The physical structure of the tree is kept isolated from 
the user of the routines to the extent that only knowledge 
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that the mechanism is associative is of importance -- 
the particular lookup algorithm and storage management 
are independent of the functional use of the module. 

5, Bliss programming "tricks": 

a. Use of the constant case expression for sub- 
fields of structures (NODE in this case); 

b. Default use of for the omitted els e in the 

«. 
structure case defining the SUBNODE field; 

c. CELL remapped in the INITNODE routine to take 
advantage of knowledge of the physical layout 
of the node's storage. 

d. "Dynamic" bind s of LEFT and RIGHT inside the 
loop in the test version discriminatio'i function; 

e. The bind to a plit (of NAMES) in the test por- 
tion, to prevent duplicate storage allocation 
for the tv7ice-used plit ; 

f. Stores into routine cells in the test program loops; 

g. Use of the plit length word preceding the plit 
(NAMESC-1]). 
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ABSTRACT 

It has been proposed, by Dijkstra and others, that the use of the 
goto statement is a major contributing factor in programs which are 
difficult to understand and debug. This suggestion has met with con- 
siderable skepticism in some circles since goto is a control primitive 
from which a programmer may synthesize other, more complex, control 
structures which may not be available in a given language. This, paper 
analyzes the nature of control structures which cannot be easily syn- 
thesized from simple conditional and loop constructs. This analysis 
is then used as the basis for the control structures of a particular 
language. Bliss, which does not have a goto statement. The results of 
two years of experience programming in Bliss, and hence without goto 's, 
are summarized. 
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INTRODUCTION 

(_^ Ii^ 1968 E. W. Dijkstra suggested, in a letter to the editor of the 

Communications of the ACM [1], that use of the goto construct of Algol 
was undesirable, and in fact was bad programming practice. The rationale 
behind this suggestion was simply that it is possible to use the goto 
in ways which obscure the logical structure of a program, thus making it 
difficult to understand, debug, and, ultimately, to prove its correctness. 
Of course, not all uses of the goto are obscure, but the conjecture is 
that these situations are adequately handled by existing conditional (e.g., 
the if - then - else) and looping ( for-do) constructs. 

This paper presents an analysis which lead to the design of the 
control features of Bliss [5], an implementation language designed at 
Carnegie-Mellon University. This analysis reveals that the Algol condi- 
tional and looping constructs are, while adequate, not convenient when 
the goto is eliminated. The control features of Bliss are described and 
some comments are made concerning our experiences using a goto-less, 
Algol -like language. 

Before proceeding it is worth noting an additional benefit of removing 
the goto - a benefit which the author did not fully appreciate until the 
Bliss compiler was designed - that of code optimization. It is clear that 
the presence of ^oto in a block-structured language with dynamic storage 
allocation forces a certain amount of run-time support (and overhead) 
associated with the possibility of jumping out of blocks and procedure 
bodies. Eliminating the goto obviously removes this overhead. Far more 
important, however, is the fact that the scope of a control environment 
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is statically defined in a program vzithout goto 's. The Fortran-H compiler 
[2], for example, does considerable analysis and achieves a less perfect 
picture of the overall control structure of a program than that implicit 
in the text of a Bliss program. Since analysis of control flow is pre- 
requisite to any form of global optimization, this benefit of eliminating 
the goto must not be underestimated. 

It is not surprising that a language can be devised which does not 
use the goto construct since: (1) several of the formal systems of 
computability theory, e.g., recursive functions and the X-calculus,. do 
not contain the concept; (2) LISP does not use it; and (3) Van Wijgaarden 
[3], in attempting to define the semantics of Algol, eliminated labels 
and goto's by systematic substitution of procedure bodies and calls. 
Thus, the question is not whether it is possible to remove the goto , 
only whether it is desirable. In particular there is considerable suspi- 
cion among programmers that the advantages described by Dijkstra are out- 
weighed by inconvenience, and possibly by inefficiency (duplicate code, etc.). 

The goto may be viewed as a control primitive with which a programmer 
synthesizes more complex control structures. In this context Dijkstra' s 
arguments can be phrased in terms of this primitive having "unwanted 
generality". The principle concern of this paper is to investigate alter- 
native primitives which are equally convenient for the things which pro- 
grammers actually do. 
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ANALYSIS 

In order to determine the nature of the control primitives to sub- 
stitute for the ^oto, we shall first consider the nature of programs 
which use the goto and which cannot be easily built from simple condi- 
tional and looping constructs. To do this we will use a flow chart rep- 
resentation of programs. Flow charts are convenient for this because of 
the explicit way in which control is manifest in them. We assume two 
basic blocks from which our flow charts are to be built - process blocks 
and n-way conditionals. 



process box 




n-way conditional 



These boxes are connected by directed line segments in the usual v/ay. We 
shall further be interested in two special "goto-less" constructions built 
from these components - simple loop and n-way "case" constructs. 





simple loop 



case 
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We consider these two forms "goto-less" since they contain a single entry 
point and a single exit point and hence could have reasonable corresponding 
syntactic constructs in some higher-level language (and indeed db ) , Now, 
consider three transformations: 

1, any linear sequence of process boxes may be transformed 
into (or replaced by) a single process box 



3 






— » » «. — ^ 



>-^ 



2. any simple loop may be replaced by a process box 




Z^ 



3. any n-way case construct may be replaced by a process box 




.^^ 



^' 



The simple loop considered here clearly does not correspond to all possible 
varients of initialization, test before or after the loop body, etc. These 
varients would not change the arguments to follow in any essential way and 
hence have been omitted. 






3-6 



c 



Any graph which may be derived from a given graph by a sequence of 
these transformations we shall call a "reduced" form of the original 
graph. A graph which has a reduced form consisting of a single process 
box we shall call a simple "goto-less" graph. The sequence of trans- 
formations .is said to define a set of nested "control environments". 

Not all graphs are of this type; these are of special interest to 
us since they typify the class of control structures which cannot be 
realized by simple conditional and looping constructs. In looking at such 
graphs we are principally interested in their "minimal irreducible form"; 
that is, a reduced form to which no more transformations of the type 
described can be applied. Examination of these graphs will both reveal 
techniques for deriving simple goto-less graphs from them, and also pro- 
vide insight leading to the control primitives to be described later. 

Before proceeding it is perhaps instructive to remark briefly on 
Dijkstra's objections to the goto in terms of this characterization of 
programs. By definition, a goto-less program (flow chart) is susceptible 
to a sequence of simple transformations which reduces it to a single pro- 
cess box. This sequence can serve as guide to understanding and/or 
proving the correctness of the program. Imagine a sequence of graphs, 
derived from the original, in which each is like its predecessor except: 

(1) the correctness of the replaced construct has been verified, and 

(2) the new process box contains a more macroscopic description of what 
the replaced portion does (rather than the details of how it is done). 
This sequence forms both a proof of the validity of the entire original 
program as well as documentation of what it does (at many levels of detail) 
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This is not to say tliat programs that use goto cannot be understood or 
proved correct [6], only that programs with this structure permit a 
specific methodical approach to understanding and proof. 

Now, returning to an analysis of programs which use goto , consider 
two cases .- those with loops and those without. Programs without loops 
have, at most, a lattice-like structure. For example, consider the follow- 
ing irreducible form (in this example, and the remainder of the paper, we 
shall use circles to represent sub -graphs whose fine-structure we choose 
to ignore) ; 







Brief consideration of such graphs reveals that it is al^^ays possible 
to construct a new graph using only the goto -less primitives which are 
similar to the original graph except for a finite number of "node splittings" 
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(i.e., creation of duplicates of existing nodes in separate control paths). 
This follows from the observation that, since there are no loops, there 
are at most a finite number of paths through the graph and each node occurs 
on only finitely many of them. Hence at most a finite number of replica- 
tions of each node will guarantee that each node will occur on only one path, 
For example, the graph above becomes: 




c 



And this graph can now be transformed by collapsing <2,5'>, <3,5,6>, and 
<4,6'> into: 
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This is one of the primitive forms and may itself be collapsed - and hence 
is a goto -less program. 

Node splitting is something which we would like to avoid since it 
involves duplicating code. Nevertheless, node splitting is one technique 
by which an existing program utilizing the got o may be converted into one 
which does not. A second technique, which also might have been used above, 
will be discussed in conjunction with loops below. 

The second major case to be considered is that of irreducible graphs 
involving a loop. Of these we can note that such loops must involve more 
than one entry or exit point. Otherwise the loop would be reducible, 

Floyd and Knuth [4] have proven (using flow charts as specifications 
for regular expressions) that node splitting is not an adequate technique 
for deriving goto-less graphs from irreducible ones in the presence of 
multiple entry/ exit loops. ^ 

That node splitting is inadequate becomes clear by simply observing 
that the number of paths leading from the "second" exit point is unbounded. 
Therefore no finite number of replications of this node is sufficient, and 
we must search for another technique. Consider the following irreducible 
program: 



it 

We reiterate our earlier footnote - we have only considered one form of 
simple loop - introducing varients on the initialization or relation of 
the test to the loop body would not affect these arguments in any essential 
way. 
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Notice that there are two exit paths from the (l) -(3) loop - that leading 
from (T) to (2) to (4) and that leading from (3) to © directly. This 
is a simple example of a program where node splitting will not work. 
However, one can introduce a nex^ variable, call it a, and obtain the 
follovzing graph: 
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In this graph the node Qj) is like node (l) except that the exit 
condition of the loop has been augmented with "or_ a = 0" and node (3j) 
is like node @ except that the exit to node @ has been replaced by 
the operation "a <- 0". Node (5) is the null operation. Conceptually 
what we have done is to introduce a variable which behaves as a "program 
counter" and which, when the loop terminates, specifies whether or not 
it is necessary to execute ^2) . 

That the technique illustrated above is completely general may be 
seen easily. Consider any graph with nodes labeled (^ , C2) , ..., (n) 
Now construct a new graph as follows: 

1. if Tij is a process box construct (iy by adding to fi) 
"a *~ 1^" where (V) is the successor of (i) . 

2. if C±) is a decision box, then replace it by a process 
box of the form "or *- €", where 6 is an expression which 
dynamically evaluates to the appropriate successor label, 

3. consider all exit points as labeled by (o) 

4. construct the following graph 
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exit 



As with node splitting, this technique is odious because of the 
implied inefficiency. But also, it is a technique which may be applied 
to convert any existing programs with gotos into ones vzithout them. And, 
in particular, the techniques may be applied locally to irreducible sub- 
graphs . 
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The Bliss Co ntrol Struct ure 

The previous section points out the nature of programs which may be -^ 

constructed with only conditional and looping constructs - and those which 
cannot be constructed without duplicating some nodes or adding dummy 
variables, etc. The present section addresses itself to the question of 
whether the class of constructs in a practical language (which will not 
contain an explicit goto) should be extended beyond simple conditional 
and looping facilities. And, if the decision is to extend the class, then 
what should the extensions be? The answer to the first of these questions 
depends in part on a judgment as to the frequency with which multiple exits 
from loops, etc., are used, and in part on the answer to the second question. 
Whether to add constructs or not depends upon whether it can be done in 
such a way as to preserve the structural advantages which prompted us to 
consider a goto-less language in the first place. Hence we must answer 
the question of a specific language proposal. Part of this section will 
be devoted to a description of the facilities in Bliss to give some back- 
ground for discussing this question. 

Note that we are principally interested in programs which are initially 
written in such a goto-less notation rather than in translating existing 
programs into the notation. Consequently, we are willing to accept some 
restrictions on what can be written - so long as the "common" things are 
expressed conveniently. Even the goto is not completely general in most 
languages - one may not jump into the scope of a DO statement nor out of 
a subroutine in FORTRAN, and jumping into the middle of a block from out- 
side it is prohibited in Algol. Neither of these restrictions is a serious 
one in practice. 
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The three "problem areas" discussed in the first section were: 
(1) lattice-like decision structures, (2) multiple entry points to a loop, 
and (3) multiple exits from a loop. Without any hard evidence at our 
disposal we are left with only our intuition and experience to v?eight the 
importance of these constructs. In particular, the author believes that 
(1) and (3) are both quite important, and only one subcase of (2) is 
important - namely, that case involving selection of one of several initi- 
alization sequences. One might make a different evaluation and arrive at 
a different set of facilities than those to be. described below. 

The first aspect of the Bliss control structure is simply the fact 
that it is a block-structured "expression language". Tliat is, every 
executable construct, including those which manifest control, is an expres- 
sion and computes a value. There are no statanents in the sense of Algol 
or PL/i. Expressions may be concatenated with semicolons to form expres- 
sion sequences. The value of an expression sequence is that of its last 
(rightmost) component expression and is evaluated in strictly left-to-right 
order. Thus ";" may be thought of as a dyadic, left associative operator 
whose value is simply that of its righthand operand. A pair of symbols 
begin and end, or left and right parentheses, may be used to embrace such 
an expression sequence and convert it into a simple expression. A block 
is merely a special case of this construction which happens to contain 
declarations, thus the value of a block is defined to be the value of its 
constituent expression sequence. 

The fact that Bliss is an expression language is relevant to the goto 
issue in the following way: the most general method described in the first 
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section for translating programs into go to-less form was that involving 

a dummy variable which explicitly indicates the successor. Tlie value of 

an expression (a block, for example) fonns a natural implicit node of 

expressing this idea. This will be illustrated after some of the explicit 

control expressions have been discussed. 

There are six explicit control expressions in Bliss: conditional, 

loop, case-select, function, co-routine, and escape. We have avoided 

consideration of subroutines in the previous material and so shall omit 

« 
functions and co-routines from this discussion. 

The conditional expression 

if €-| then G, else €^ 

is defined to have the value of the expression ^ just in the case that 
^- evaluates to the Bliss representation of true and has the value of 
^ otherwise. The abbreviated fona "if_ €-, then C" is considered to be 
identical to "if_ €, then €« else 0". 

The conditional expression provides two-way branching, the case and 
select expression provide more general n-x7ay branching: 



case e„,e 



0'' 



1 , . . , , e of set €q ; €-, ; . . . ; € tes 



select eQ,e^,...,e^ of set €q:€p ^i^\ ... ; ^^t ^^^^^ tesn 

The case expression is executed as follows: (1) all of the expres- 
sions ef^,...,e are evaluated, (2) the value of each e (0 ^ i ^ k) is, 

UK. "^ 

in turn from left to right, used as an index to choose one of the €. ' s 
(0 ^ j ^ n) to be executed. Obviously, each of the e.'s is constrained 
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to lie in the range s: e^ ^ n if one of the G's is to be executed, in 
the current implementation if e. = -1 none of the €'s will be executed and 



execution is undefined for all other values of e. . rne value of the enti 



re 



case expression is f . The special case vzhere lc=^l is of special interest 

k 
and has appeared in several other languages, ALGOL-W and EULF^R 

for example c 

"^^^ s^^gct expression is similar to the case expression except that 
the e^'s are not used as indices. Rather, the e's are used in conjunction 
with the €2.'s to choose among the ^-.n's. Execution proceeds as follov/s: 
(1) all of the e 's are evaluated, (2) ^ is evaluated, (3) if the value 
of 6p is identical to the value of one (or more) of the e's then €. is 
executed, (4) ^ is evaluated, (5) if the value of ^ is identical to the 
value of one (or more) of the e's then C is executed, etc. Tlie value of 
the entire select expression is simply that of the last G, . , n to be executed 
or -1 if none of them is executed. 

The utility of the fact that Bliss is an expression language may be 
illustrated using the case expression in an earlier example, namely the 
flow chart: 
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This graph may be thought of as actually of the forai 




3 



where Qn is formed from (l)»(2j), and (3) as follows 
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Which means that one might write in (pseudo) Bliss: 

case case ® of set (®;O);(0; OV1);(0;1) tes of 
set (5); (6) tes ; 

© 

This provides a neat, conceptually simple, and efficient alternative 
to node splitting. 

Returning now to the discussion of Bliss control forms, the loop 
expressions imply repeated execution (possibly. zero times) of an expression 
until a specific condition is satisfied. There are several forms, some of 
which are: 

while 6-, do 6 

do € while €, 

incr <id> from 6-, to €» by ^ do ^ 

In the first form the expression 6 is repeated so long as €, satisfies the 
Bliss definition of true . The second form is similar except that € is 
evaluated before G-i thus guaranteeing at least one execution of €. The 
last form is similar to the familiar " step , . .u ntil" construct of Algol, 
except (1) the control variable, <id>, is local to €, and (2) 6-.JC and £^ 
are computed only once (before the first evaluation of the loop body, O. 
Except for the possibility of an escape expression within € (see below) 
the value of a loop expression is uniformly taken to be -1. The particular 
choice of -1 as the value of a loop expression is not important except that; 
(1) it is uniform, and (2) there are some small advantages to this choice 
in connection with the definition of the case expression and zero origin 
data structures. 
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The control mexhanisms described above are either similar to, or 
only slight generalizations of, the conditional and loop constructs of 
many other languages. Of themselves they do not solve the problems 
discussed in the first section. Another mechanism is needed - that mech- 
anism is called the escape expression. An escape expression provides a 
highly structured form of forward branch. The branch is constrained to 
terminate coincidentally with the terminus of some control environment 
in which the escape expression is nested. The general form of an escape 
expression is 

<escapetype> <levels> <expression> 

where <escapetype> is one of the (reserved) words listed below and <levels> 
is either an integer enclosed in square brackets, e.g., "[3]", or else is 
empty (which implies [1]). 

exitblock exitcase 

exit compound exitselect 

exitloop exit 

exit conditional return 

An escape expression causes control to immediately exit from a specified 
control environment (a block, a compound, or a loop, for example) skipping 
any subsequent expressions in that environment. The <levels> construct 
permits exit from several nested loops, for example, with a single exitloop 
expression. The <expression> value in an escape expression defines the 
value of the environment from which control passes. 
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The use of the escape expression is illustrated by a typical problem 
involving multiple exits points from a loop. Suppose a vector, X, is to 
be searched for a value, x. If an element of X is equal to x, then the 
variable, k, is to be set to the index of this element. If no element 
of X is equal to x, then the value of x is to be inserted after the last 
element of X and k set to this index. Supposing there are N elements 
currently in X. Tlie following Bliss program' will perform this task. 

il (^ *" J^"c^ i from 1 to N b;^ 1 do i£ X[i] = x then exi tloop i) < 
then X[k *- N «- N+1] ^ x; 

We can now return to the original questions raised in this section. 
We know that the mechanisms are "adequate", but are they sufficiently 
convenient and do they preserve the desirable properties of goto-less-ness. 
The answer to the first of these questions lies principally in the experi- 
ence of those who have used the language. These experiences are summarized 
in the next section and essentially answered in the affirmative. Some 
confidence that this is the case may be gained by simply viewing the escape 
mechanism as a specific device for handling multiple exit point loops, and 
viewing the decision to make Bliss an expression language as a specific 
tool for implementing the dummy variable technique. In fact, of course, 
both ideas are more general than this. 

The second question, whether the Bliss structures retain the desirable 
properties of simpler goto-less notations, requires a little more consider- 
ation. First, it is only the escape mechanism which violates the goto-less 
criteria. Returning to the flow chart notations, we now think of our flow 
chart primitives as: 



Actually the given program is not Bliss, but the differences are not 
essential to the discussion of control. 
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where the dotted lines represent a potentially infinite set of flow lines 
one of which may be followed if the escape mechanism is invoked. Dotted 
flow lines are constrained to connect directly to the terminus of a 
control environment in which the initial point of the line is totally 
nested, 

the previous set of transformations is still applicable if the dotted, 
"escape", flow lines are ignored and we are guaranteed that the escape 
lines will be totally enclosed at some stage in the reduction process. 
In this sense the desirable properties of goto-less graphs are retained. 
The simple technique for understanding a flow chart and proving its cor- 
rectness is no longer possible, however, because control is no longer 
constrained to exit through a single path. Nevertheless, a similar tech- 
nique is easily constructed. It simply must operate in more global contexts 

One can clearly apply the former style of reasoning to subgraphs from 
which no dotted lines emanate. After this has been done on all possible 
subgraphs attention must shift to as small a subgraph as possible which 
wholly contains its escape lines, and understanding be gained and verifica- 
tion done on this subgraph as a whole, and reduced as a whole. This may 
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or may not lead to the simpler form of graph, but in either case the 
process can be iterated. 

Some Experiences 

Bliss has been in active use for nearly two years and we have there- 
fore gained considerable experience in prograiratiing without the goto - both 
in writing new programs and in translating previously existing ones. This 
experience includes several compilers, parts of an operating system, i/o 
support routines, as well as numerous applications programs. As one might 
expect, writing new programs presents no difficulty. Just as one adapts 
to the lack of recursion in Fortran or the inability to jump into the 
middle of an Algol block, one also adapts to the Bliss control structure. 
But it is not that one merely survives in this mode; quite the contrary. 
One develops a mode of thinking whihc is roughly the inverse of the reduc- 
tion transformation sequence discussed in the first section. That is, one 
thinks, and writes from the more macroscopic to the most detailed levels. 
We have not conducted controlled experiments, but I am convinced that 
programmer productivity has significantly improved duk to this enforced 
style of programming. 

In some sense our experiences in translating existing programs are 
even more interesting than those in writing new ones. These latter experi- 
ences fall in two sharply defined categories - the times when it was easy 
and the times when it was hard. Most of the time it was easy, because most 
of the time programmers apparently use goto 's in non-essential ways; that 
is, ways which mirror one or more of the constructs already in Bliss. On 
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the other hand, when the translation was difficult the real problem was 
understanding what the original programmer had intended the control 
structure to be. Once that was done, in every case (to my knowledge) 
there was a natural mode of expression in Bliss. There were surprisingly 
few cases v/here node splitting, or any of the other devices mentioned, 
were necessary. If we assume that the programs we have translated are 
representative, and I do not know that they are, then we must conclude 
that programmers do not use the generality of the goto . 

We have found two aspects to the Bliss structure which are inconveni- 
ent and should be changed. One is a trivial syntactic change and is easily 
accomplished; the other is more fundamental. The "<levels>" construct in 
escape expressions embodies an important semantic notion, but the syntax 
should be changed. As a program is modified the number of levels through 
which an escape should execute may be changed - by the introduction of an 
additional block level, for example. One would like to indicate the target 
of the escape symbolically. Which is to say labels should be reintroduced 
as names of entire control environments. The other construct I should like 
to have is, intuitively, one which allows exit through several levels yof 
subroutine call - either to a specific place or until a specified condition 
is met. 

Whether or not a language includes the goto construct is immaterial. 
There are certain types of control flow which occur in real programs and 
if constructs are not explicitly provided for these then the goto must be 
provided so that the programmer may synthesize them for himself. The 
danger in permitting the goto is that the programmer will synthesize them 
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in weird and obscure ways. The advantages in eliminating the goto are 
that these same control structures will appear in regular and well-defined 
ways and consequently both the human reader and the compiler will do a 
better job of interpreting them. 
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WHY THE DOT? 

The interpretation of the occurrence of identifiers in Bliss is 
different from that in most programming languages - and this difference 
has given rise to questions and suggestions from almost everyone who is 
first introduced to the language. The purpose of this memo is to, or 
at least attempt to, explain the reason for the chosen interpretation. 
The chosen interpretation is quite fundamental to the intent and structure 
of the language and was decided upon only after extensive, heated debate 
and is not merely a whim of the designers; to change it would do substan- 
tial violence to the language and could only be accomplished through 
the introduction of a large number of ad hoc rules if the other inten- 
tions of the language were to be preserved. 

First let me review the interpretation, although I'm assuming some 
acquaintence with the language. An identifier is introduced into a Bliss 
program by a declaration; for example 

own x; 

There are scope rules as in Algol '60, but let's ignore them and assume 
that X is not re-declared at an inner block level. Now, anywhere in the 
scope of this declaration, independent of the context in which it occurs , 
an occurrence of the identifier is interpreted to mean a reference* to 
the memory cell allocated by the declaration. Thus the value of the 
expression "x+1" is one larger than the address of x rather than the value 
contained in the memory cell x. Thus, one may think of the occurrence 



*A reference, or pointer, in Bliss is a fairly complex object, but for 
this discussion it is adequate to think of it merely as the address of a 
memory cell. The remainder of the discussion presumes this simple 
interpretation . 
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of an indentifier, x, as the occurrence of a literal (the address of x) 
where the value of the literal is bound at load (or possibly execution) 
time. J 

Clearly one wants to obtain the value stored in a memory cell as 
well as its address. For this purpose the unary dot, ".", operator is 
introduced. The value of the dot operator applied to an expression, 
^, is that of the memory cell whose address is ^. Thus, ".x" is the 
value contained in the memory cell x, ".(x+1)" is the value of the memory 
cell whose address is one greater than that of x, "..x" is the value 
of the memory cell whose address is stored in the memory cell whose 
address is x (i.e., indirect addressing), etc. 

Closely associated with the interpretation of identifiers and the 

dot operator is that of the store operator 'V , which is also different 

from that usually given in the description of conventional languages 

(though not different from its implementation) . The store operator is a 

dyadic, infix operator whose operands may be arbitrary expressions, -^ 

say €-L and €2* 

^l*-^2 

The value of lefthand operand 6, is interpreted as a pointer (address) 
which names a cell into which the value of the righthand operand, 6 , 
is to be stored.* 

Before turning to the issue of "why" the interpretation is as it is, 
I'd like to make three comments. First, the only people who have ob- 
jected to the interpretation are those who first encounter it; to my 



*The value of the store operator is € , but that's not relevant to this 
discussion. 
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knowledge no one who is using the language objects. That only proves 
that it's possible to learn to live with it. Second, while the inter- 
pretation may be unique among higher level languages, it is precisely 
the interpretation adopted in assembly languages. Third, the interpre- 
tation is entirely consistent, the interpretation of an identifier is 
exactly the same independent of the context in which it occurs. (May- 
be we could coin a phrase: "context-free semantics".) 

Now, let me finally turn to why the interpretation is as it is. One 
of the fundamental design objectives of Bliss was to permit the user to 
define arbitrary representations of data structures by permitting him 
to define the accessing algorithm (expression) for elements of the 
structure. This implies not only that the user must be able to mani- 
pulate pointers as flexibly as values, but also that the value of an 
arbitrary expression must be able to stand as a name. This implies, 
for example, that the assignment operator must permit arbitrary expres- 
sions fe^ and 6"^ in the context €•♦•€,. 

An alternative to the Bliss interpretation of identifiers and dot 
operator is to assume that identifiers always represent the value of a 
variable and introduce another operator, say OL, which means "the address 
of". One would still need the dot for several levels of indirection, 
but simple expressions such as (in current Bliss) 

x^- .x+1 

would be written 

o^x*-x+l 
Since, presiamably, thre are fewer instances of addresses than values, 
there should be considerably fewer <»C' s to write with this scheme than 
dots in current Bliss programs. Carrying this reasoning further, why 
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not presume el's on the left of assignments (or, almost, equivalently 
dots on the right) ? Then one could write 

x^- x+1 

which is more familiar. Under this scheme one could, of course, write 
oC's or (extra) dots to override the standard interpretation. Thus 

.x*-l 

would store indirectly through x, and 

x*-ecy 

would store the address of y in x. Or would it? Let's examine some 
of the difficulties that arise from such an interpretation. None of 
these difficulties is insurmountable; however, they lead to a large col- 
lection of ad hoc interpretat on rules. 

Above I suggested that x«-Ky would store the address of y into x. 
One may think of * as either an operator, or merely as a compile time 
notation which overrides the suggested "value of" interpretation. If 
one chooses the first of these interpretations, then cCy ought to mean 
the address of the value of y (i.e., otCy))- which is not unique 
(there may be many locations whose current value is the same as that 
of y) . Moreover, the expression 0<^(where €• is an arbitrary expression) 
seems to have no useful interpretation unless one is willing to store ^, 
create a reference to this location, and support the garbage-collection 
that that implies. The "compile-time override" interpretation of 0^ has 
its own set of problems; it makes 'o<y' do something reasonable, but ^£ 
is nonsense and an arbitrary rule would have to be introduced to pro- 
hibit it. (What does p((l+2) mean?) On the other hand, o^^ is exactly what 
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you want in an expression such as 

Q X4-0(y[i] 

in which you wish to store the address of a structure element into x, 
so you must allow this case, too. It gets worse, as you'll see 
below. 

Suppose, for the moment, that you've contrived some interpretation 
rules which handled the problems mentioned above, and that you move on 
to the implied ^' s (or dots). You are now faced with the problem of 
deciding what's on the left and what's on the right of an assignment 
operator. There's no problem with x*-y, but what about 

(x+i) ♦- 5 

Given the initial assumption that accessing is specified by an arbitrary 
algorithm, this is hardly an implausible thing to write. But what does 
it mean? It must be one of (in Bliss) 

(a) (x+i) ♦-S 

(b) (x+.i) ♦- 5 

(c) (.x+i) ♦- 5 

(d) (.x+.i) ♦- 5 
Relying on accumulated experience with respect to the usual way of 
storing vectors one might like for the interpretation to be (b) , but 
I can find no rational reason for adopting this one; (a) or (d) seems 
more plausible, and (a) the most plausible. O.K., suppose you try to 
be consistent, and so you adopt (a) and then you write 

(x+.i) ♦- 5 
to explicitly indicate that, even though i appears on the left of an 
assignment, you want its value, not its address. You're now in trouble 
with another design objective of Bliss; namely, that the same accessing 
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function be usable everywhere. If you write 

y#-(x+.i) 
which means (in Bliss) 

y ^ ( . x+ . . i ) 
you do not get what was intended at all. 

Again, you can gin-up a rule to cover this case. However, suppose 
that an accessing algorithm is specified by a function, f , and the body 
of f contains the expression " return x" . Should this expression re- 
turn the value or the address of x? In the expression 

f ()♦- f 0+1 
both are needed. Of course f could return both, but then consider 

g() -^ g()+l 
where the body of the routine g contains 

return f ( ) 

Must g now return (1) the address of the address of x, (2) the address 
of the value of x, (3) the value of the address of x, and (4) the value 
of the value. WOW! 

Having examined the consequences of some of the alternative pro- 
posals, let's now consider the reasons behind them. There are two: you 
are forced to write a lot of dots, and it deviates from the "standard", 
or "conventional". The first of these arguments has merit, and in fact 
was the rationale for choosing an inconspicuous, easily written and typed 
graphic for the "contents of" operator. In practice, however, users 
of the language have found little difficulty in either reading or writing 
the dot. The second argument is simply absurd. There is no standard 
since there are no other languages which deal with the same issues, 
except possibly assembly language, and Bliss uses the same convention as 
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assembly languages. 

As for the virtues of the convention, it is simple and completely 
consistent, it permits accessing algorithms to be written and used 
in all contexts, and it covers all the cases. The distinction between 
name and value is a fundamental one, and in my opinion it is far more 
important to treat it explicitly and consistently than to provide 
minor convenience to the uninitiated. 
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ABSTRACT 

The specification of data structure in higher-level languages is isolat- 
ed from the related specifications of data allocation and data type. Structure 
specification is claimed to be the definition of the accessing (addressing) 
function for items having the structure. Conventional techniques for data 
structure isolation in higher-level languages are examined and are found to 
suffer from a lack of clarity and efficiency. _^^ 

The means by which data structure accessors may be defined in Bliss, ) 

the specification of their association with named, allocated storage, and their 
automatic invocation by reference to the named storage only, are discussed. An 
example is presented which illustrates their efficient implementation and their 
utility for separating the activities of data structure prograiraning and algorith- 
mic programming. 

INTRODUCTION 

Since the management and representation of data are of prime interest 
in programming, we wish to present the view of data structures that has been 
adopted in the implementation language Bliss. Bliss [1] is a higher-level 
language designed for writing large software systems for the PDP-10 [2] and 
is currently being implemented at Carnegie-Mellon University. Our paper is 
divided into two parts. First we discuss the issues which arise in defining 
and implementing data structures in higher-level languages. Then we present 
the facilities in Bliss which are designed to handle the representation of 
data. 
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HIGHER-LEVEL LANGUAGE DATA STRUCTURE SPECIFICATION 

THREE ASPECTS OF DATA SPECT '> ";ATION 

We begin by considering three aspects of data structures which are not 
separable in most higher-level languages, but which can be separated in Bliss 
to allow greater flexibility in data specification: 

1. Type specification - the name of a piece of data specifies its 
internal format and the class of operators for which it is a 
valid operand. 

2. Allocation - the presence of a named data item requires that 
we be able to associate this name with its value; presumably, 
that value will require space in the underlying logical machine. 
The format (and perhaps the size) of the allocated space depends 
on the data type specified for the name. The scope rules of a 
language define the domain of valid access to a value via its 
name. The logical machine manages the allocation of space for 
storing the value and is free to overlay non-contemporaneous 
allocations. 

3. Structure - tlie ability to structure regions of storage allows 
us to generate in a simple way a large collection of names and 
to retain the logical clarity of a generic name. Indeed we 
want the ability to compute a name (e.g., array subscript compu- 
tation) and to sequence through a collection of names. 

Taking Algol [3] as an example, the text 

procedure P(A.B) ; real array B [1:1001; ... 

provides a structure for B and types the elements of the structure (named: 
B[l], B[2], ..., B[100]). Furthermore, in addition to structuring and typing, 

begin real array B [1:100]; ... 

also allocates space. We emphasize: two different Algol implementations may . 
physically structure the same logical structure differently (e.g., dope vector 
vs. by column or row). 



IMPLEMENTING A FOREIGN DATA STRUCTURE 

We consider in some detail how we build a data structure in a higher- 
level language whose inherent data structures may be quite different from those 
to be implemented. In particular consider a partial implementation of Lisp [4] 
in Algol, Atoms will be stored in an array with negative indices for non-null 
atoms and the zero indeix will indicate NIL, Cells will be stored in a two 
dimensional integer array with positive indices. 

Now we examine two ways of implementing the Lisp accessing functions 
CAR and CDR. 
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(1) integer array ATOMSPACE [-1000:0]; 
integer array CELLSPACE [1:10000,1:2]; 
integer procedure CAR (I) ; integer I; 

CAR := CELLSPACE[I,1]; ^ 

integer procedure CDR(I) ; integer I; 
CDR := CELLSPACE[I,2]; 

(2) integer array ATOMSPACE [-1000:0]; 
integer array CAR [1:10000], CDR[1: 10000]; 

Note that in both implementations the Algol array bounds checking will handle 
the error resulting from attempting to access the CAR or CDR of an atom. 

Several things are to be noted about these two implementations. Both 
(1) and (2) implement the same logical structure. The accessing structure is 
logically independent of the allocation since the declarations could appear in 
any Algol block at any level. The foreign types atom and pointer had to be in- 
corporated into the structure of the implementing language. Implementation (1) 
has an advantage over (2) in that it can be modified more easily. We can change 
the body of the accessing functions CAR and CDR without changing the program's 
reference to them. On the other hand (2) is clearly more efficient than (1) 
since it employs the built-in accessing mechanisms of the Algol machine whereas 
(1) req]jiires execution of the expensive procedure calling mechanisms of Algol 
procedures. Of course, neither implementation is as efficient as a direct 
machine language implementation of Lisp. Hence we can isolate a major difficulty 
that arises from specifying a data structure in a higher level language. In 
general we pay, a high price in lost efficiency by implementing a data structure 
in a higher-level language unless, of course, that language is designed to make 
such implementations efficient. For example, if pointer or address were an 
Algol type, we could probably improve the above implementation to a point where 
the cost would be tolerable. 

ISOLATING DATA ACCESS 

We examine the motivation for isolating access to data. Consider the 
following Algol statement: 

X := (Y[I] mod 2 t (WORDLENGTH - 14) -r (2t (WORDLENGTH - 22)); . 

The code extracts bits 14 through 22 of Y[I] and stores it into X (where 
"WORDLENGTH" is the number of bits in a machine word and bits are numbered 
from the left). It seems evident that we would not want to write this rather 
cumbersome piece of code for each access of this subfield Y[I]. A major con- 
sideration in having structured identifiers in a language is to improve the 
clarity and readability of the program. It is also true that most programs 
are subject to fairly substantial modification as they are being built. Quite 
obviously the decision to change the format of the variable Y[I] so that the 
subfield of interest was no longer bits 14 through 22 but 7 through 15 would 
mean a laborious change of all the code that accessed that information. 

At present most higher-level languages allow at best two ways of isolat- 
ing accesses to data items whose structures are not built into the language — 
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macros and procedures. We can define one procedure as an accessor for a whole 
class of data items by passing information via parameters. Alternatively we 
can define a procedure as an accessor for a particular data item by allocating 
space for the data as an own variable of the procedure. 

For example, assume that a linear array is being used to represent the 
elements of a symmetric matrix. The sjmimetry of the array allows the overlay 
of elements off the main diagonal. We "define the following procedures for 
reading from and writing into arrays of this form: 

real procedure LOADSYMMETRIC(A,I,J) ; real array A[l:100]; 
integer I, J; 

LOADSYMMETRIC := if I > J 

then A[I*(I-l)-r2+J] 
else A[J*(J-l)-r2+I]; 
procedure STORESYMMETRIC (A , I , J . V) ; real array A[1:1001; 
real V; integer I, J; 
if I > J 

then A[I*(I-l)-s-2+J] := V 
else A[J*(J-l)-r2+I] := V; 

The intention is for these accessing procedures to serve for several such arrays, 
If we wish to apply this structure to only one symmetric array, then the formal 
parameter A can be omitted (and A declared an own variable within the procedure), 

We can avoid the expense of the function call mechanism by using string 
replacement macros. 

macro LOADSYMMETRIC (A, I, J) = 
if I > J 

then A[I*(I-l)-r2+J] 
else A[ J* (J -1) •7-2+1]; 
(_ macro STORESYMMETRIC (A,I,J,V) 

if I > J 

then A[I*(I-1)-t2+J] :« V 
else A[J*(J-l)-r2+I] := V; 

Both these solutions have drawbacks: 

(a) As mentioned previously, function calls are unattractive 
because of their inefficiency. 

(b) The presence of two accessing functions for one logical 
structure is required because of the left/right distinction 
in assignment statements. 

(c) If a macro or procedure is defined for a whole class of data 
items and we decide to change the logical structure of one 
of the data items, then we must search the entire program 
for calls on the macro or procedure to change its structure. 

(d) Macros have their own problems. Consider: 

macro A(B,C) = if GLOBALBOOLEAN then B[C+3] else B[C-3]; . 

If "GLOBALBOOLEAN is redeclared in an inner block, subsequent use 
of the macro will have the possibly undesirable effect of testing 
the new variable. Another unpleasant feature of the macro is the 
handling of actual parameters. Consider the macro call: 

Y := LOADSYMMETRIC (X,F(I) ,G(J)) ; . 
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The expansion of this call produces inefficient and potentially 
side-effect-producing results because of the multiple calls on -^ 

the functions F and G. _J) 

Having pointed out some of the issues that arise when considering how 
to implement data structures and having considered several of the problems 
associated with implementing data structures in higher-level languages, we 
next discuss how Bliss enables the programmer to specify his data structures 
and still maintain efficiency, 

BLISS DATA STRUCTURE SPECIFICATION 
NOTES ON BLISS 

Bliss is primarily an Algol-like expression language with additional 
control expressions to circumvent problems encountered removing the "go to", 
and with declarations (for allocation) to facilitate independently compiled 
modules and special machine features (e.g., registers). The only anomaly 
which is relevant to this discussion is that names stand for machine addresses. 
If we want the contents of a named location, we must use a contents operator 
(the "J'); e.g., 

y *- x+1 ; adds 1 to the address of x and deposits it in the 

word addressed by y 
(x+1)<-*y; deposits the contents of y into the word 1 past the 

address of x. 



The PDP-10 has three types of data: instructions, addresses, and 36- 
bit words upon which machine operations may act. These types are determined 
dynamically by the interpreting hardware, and type checking is of a negative 
nature (e.g., "this is not a valid address"). The necessary inclusion of 
address manipulation facilities in any system implementation language would 
entail dynamic type checking if the logical type "address" were included. 
Visions of inefficiency thus lead to the inclusion of a single data type in 
Bliss: the 36-bit word. All operations are valid on this single data type. 

Data allocation is by words in the machine; although fields within a 
word are addressable, there is no effective way of allocating a part of a 
word. Again, for efficiency reasons. Bliss allocates storage to programs in 
contiguous words. Allocation is done via explicit allocation declarations; a 
specified form of allocation is made, and the declared name is bound to the 
machine address of the beginning of the allocated storage. For example, 

own A [200] ; 

reserves 200 words of core (static) and binds the name "A" to the address of 
the allocation. The other static allocation declaration is for global stor- 
age. The effect of the allocation is the same as for owns , but the name 
becomes available to independently compiled modules which reference the vari- 
able via an external declaration. 

Local variables are local to the block in which they are declared. 
They are allocated dynamically from the normal Algol implementation run-time- 
stack. The local variable name is dynamically bound to an address; 
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begin local Q, R [30] ; . , . end 

allocates one word for Q, 30 for R and binds the names Q and R dynamically 
to their respective stack addresses. Recursive entry to a block causes recur- 
sive local allocation, unlike the own form. (This is simply the default form 
of allocation for Algol declarations; e.g. Integer A, ...) The register 
allocation declaration requires compile time binding of addresses, but causes 
a recursive saving mechanism to be invoked; e.g. 

begin register Rl ; ... end 

causes the contents of the compile-time bound register named "Rl" to be saved 
in the stack (and thereafter upon recursive entry to the block) and restored 
upon exit. 



BLISS STRUCTURES 

There are no structures "built-in" to Bliss as the array structure in 
Algol or the cell in Lisp. However, address arithmetic allows the use of any 
of the standard structures. For example, we can store the contents of C[.i, .j] 
into y (where C is a 7 x 9 array) by writing: 

y<-. (C+.i*9+.j); 

(where we have presumed zero-origin indexing In both arguments and contiguous 
row storage allocation). 



STRUCTURE DECLARATION— SIMPLE CASE 

Naturally, expressions of the above form are quite common and their programming 
would become quite tedious without the structure declaration. Its form is 
easiest illustrated by example of a 7x9 array: 

own G[63]; 

structure rowof9array[i, j] = .rowof9array+,i*9+. j ; 

map rowof9array C; 

The first declaration allocates 7 * 9 = 63 words of core and binds the address 
of the allocation to the name "C". The structure declaration defines an "access- 
ing template" for those names onto which it is mapped; its format is similar to 
that of a routine (procedure, function) declaration in which the body may refer- 
ence the name of the structure as a formal parameter. The map declaration 
associates the structure "rowof9array" with the name "C". Thereafter, whenever 
the name "C" is used followed by a bracketed list of expressions, the effect is 
as if the structure were called as a routine with "C" as the actual correspond- 
ing to the routine name (which is used as a formal in the body) and the expres- 
sions as the actuals corresponding to the formals of the structure. Consider 
the routine declaration below: 

routine rrowof9array(rowof9array,l, jX = .rowof9array+.l*9+. j; 



^^ 



The effect of the use of C [3,5] in a program would then be the same as if we 
had (declared and) called rrowof 9array (C,3,5) . A Bliss routine is analagous 
to a valued procedure in Algol; however, the value of the routine is the value 
of the expression which is the body of the routine. A routine returns a 36-bit 
word, and hence, the returned value of a routine may be stored into. 

rrowof9array(C,3,5)<- 4 

assigns the value 4 to array element C[3,5]. Remembering that C (without the 
dot) is ah address, it should be clear that the above effect is the desired 
one. 

Note that the Bliss contents operator removes the left/right-side dis- 
tinction between structure accessing for storing and accessing for retrieval 
(drawback (b) above). Also, macro side-effects are not introduced (drawback 
(d)), for the structure is effectively equivalent to a routine, i.e., actual 
parameters are evaluated only once and identifiers in the structure body remain 
in the context of the structure declaration site. 

Howev-er, we have introduced some additional drawbacks (soon to be 
removed) : 

(e) Although we have allowed the flexibility of choosing the accessing 
method, we must now write a different structure definition for 

I each length row we have; e.g., rowofl2array, or rowof7array. 

(f) To allocate storage for the array C, the own above simply allo- 
cates the number in brackets of contiguous words--we must in 
some sense know how the structure works. Hence, in the above 
we had to know to allocate 7*9=63 words. 



STRUCTURES AND MAPPING DECLARATIONS 

Both (e) and (f) are solved in Algol by the array declaration: 

" integer array C[ 1 ; 7.1 ; 9];". 

Via the above, an Algol compiler knows to substitute 9 for the row length in 
the accessing expression and to allocate 7*9 words of core for the array. 

Bliss extends the structure mechanism to facilitate this by the use 
of "incarnation formals". Use of the incarnation formals to a structure is 
indicated by not "dotting" the formal to a structure; e.g., in 

structure array2[i,j] = .array2+.i*j+. j ; 

the first occurrence of j in the body refers to the incarnation formal. It 
is bound to the corresponding "incarnation actual" when the variable is 
mapped: e.g., map array2 C[7,9]; (in this case, 9). 

Hence, the structure and routine correspondence: 

structure array2[i,j] = .array2+.i*j+. j ; 
routine rarray2(iiicformali,incformalj,array2,i, j) = 
.array2+,i*.incf ormalj+. j ; 

applies, with the accessing expression for .C[3,5] (in this case) having the 
effect of the routine call rarray2(7,9,C,3,5) . 
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The structure writer knows best the allocation size required for vari- 
r ables onto which his structure will be mapped; hence, the "size expression" 

^ and "mapping declarations" were introduced into Bliss. The size expression 
is specified along with the structure declaration (preceding it, enclosed in 
brackets) as a function of the incarnation formals for the structure and of 
compile- time constants. All allocating declarations allow the mapping of a 
structure along with its declaration; 

e.g., structure array 2 [i,j] = [i"j] .array2+.i*j+, j ; 

own array 2 C[7,9]; 

The structure declaration defines a size expression, " [i*j] ", and accessing 
template, ".array2+.i*j+. j". The own declaration; 

1, Maps "array2" onto "C"; 

2, Binds incarnation actual 7 to the incarnation formal i, and 9 to j ; 

3, Evaluates the size expression associated with the mapped structure 
with the incarnation actuals substituted; i.e. 7 * 9; 

4, Allocates the number of words returned as the value of the size 
expression; i.e. 63; 

5, Binds the name "C" to the address returned by the own allocation 
mechanism. 

AN EXAMPLE 

The utility of the Bliss data structure mechanism is illustrated by 
considering a solution to the following problem: 

We wish to solve systems of linear equations with normalized upper- 
\^ triangular coefficient matrices; i.e., 

n 
(1) X. + E c.. X. = b. for i = l,2,..,,n 
^ j=i+1 iJ J i 

We must read the coefficient matrix and then solve the system for several 
sets of constraints. We also know we will be using a paged machine and that 
the coefficient matrices may be large. 



Noting: 
(a) 


X = b 
n n 


(b) 


n-1 
X + Z 
j=i+l 



def 

c.. X, = b. - c. b = b.' for i=1,...,n-l 
ij j i in n i . 

(b) is a problem with the same specifications as (1) in one less variable. 
Thus, a solution technique is to iteratively subtract the product of the last 
found X, with the column vector (c c«, . . . c - ) from the (modified) 
constant vector (b * b^* ••• \ i'^' ^^^ then becomes b' for the next step; 
i.e., new b' = (b/ - ^^« c^^ §-' - b^» c^^^ ... b^,^ • - b^' c^.^ ^^) . 

The algorithm portion (exluding l/o and declarations) in Algol might 
be: 

for k := n step -1 until 2 do 

for i := k-1 step -1 until 1 do 
B[i3 := B[i] - C[i,k] * B[k]; 

The solution is left in the original constant vector, B. 
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A Bliss implementation (with data structures and storage allocation 
specified) which mirrors the Algol program above is: 

begin 

structure vector[i] = .vector+,i - 1; 

structure array2[i,j] = [i*j] , array 2+(.i-l)*j+(.j-l); 

own vector B[n], 
array2 C[n,n]; 
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INPUT 

deer k from n to 2 do 

deer i from .k-1 ^ 1 do 

B[.d3 <-.B[.i] - .C[.i, .k]* .B[.k]; 

OUTPUT & LOOP 



end ; 

Now, note that the above solution: 

(a) wastes space for the known zero and unity elements of the co- 
efficient matrix; 

(b) thrashes considerably (if n is large) in a paged machine, for 
the coefficient matrix is accessed by columns in decreasing index 
order, but is stored by row in increasing index order. 

It can be seen that replacing the array2 structure with: 

structure upperdiag[i, j] = [i*(i-l)/2].upperdiag + (. j-l)*(.j-2)/2 + .1-1; 

and changing the mapping of "C" from "array2" to "upperdiag", modifies the 
program in such a way that it wastes no space for the known constant elements 
of "C" and eliminates thrashing by accessing elements in the same column of 
the coefficient matrix contiguously. The logical storage map of figure 1 may 
help to see this: 



3 



1,2 


1.3 


2,3 


1,4 


2,4 


3,4 


... 


1 

n-2,n 


n-1 ,n 



Figure 1 . 

The above change preserved the "algorithm portion" of the program— it 
continues to appear much the same as the Algol algorithm — however, the increase 
in overall efficiency is significant (presuming, for the moment, that the 
structure mechanism is efficient) . The simplicity with which the change was 
accomplished indicates that "drawback (c)" has been removed. 
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SUBSTRUCTURES 

V^ Continuing to postpone the efficiency drawback, note that we would like 

to use a substructure on the columns of the coefficient matrix. We know that 
within the inner loop, each of the elements is taken from the same column, and 
thus the same multiplication ((. j-l)^(. j-2)/2) is repeated for each element in 
the column. We can indicate this substructure in Bliss via the bind declara- 
tion. This declaration is dynamic in the sense that the expression bound to is 
evaluated at execution time, upon entry of the block in which the bind occurs. 
For example j in 

bind x=,y; 

wherever x occurs in the block in which it is declared, the value of the 
contents of y will be considered its address . 

The bind declaration allows its symbol to be mapped in a manner similar 
to the allocating declarations. Hence, we may write: 

bind array2 X [7,9] = .y+3; 

This indicates to the compiler that the name "X" stands for the address which 
is the contents of y plus 3. If "X" is used as a structure access in the block 
in which the bind occurs, this address is to be considered the base of a 2- 
dimensional array with at most 7 rows and 9 columns (the semantics of the 
"array2" structure defined above) . 

Binding the name "COLUMNK" to the base of the kth column of "C" in the 
outer loop in the above program, we produce the more efficient and slightly 
^ more intuitive program: 

begin 

^ structure declarations for B and C ^ 

structure vector [i]= .vector+.i-l ; 
structure upperdiag[i,j >[i*(i-l)/2] 

.upperdiag-K. j-2)*(.j-1)/2+.i-1 ; 

global vector B[n], 

upperdiag C[n,n]; 

^ Here we would begin the outer loop .to read the 
coefficient matrix, "C". 

Here we would begin the inner loop to read the 
constant vector, "B", ^ 

deer k from n to 2 do 
begin 

bind vector C0LUMNK-C[1 , .k] ; 
deer i from .k-1 to 1 do 

B[.i]«- .B[.i]-.COLUMNK[.i]*.B[.k]; 
end 

^ Here we would output or save the solutions which have 
been left in "B". Then we would continue the inner 
and outer loops. ^ 

/— end; 
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EFFICIENCY 

Clearly, the efficiency of structure accessing mechanisms highly affects J^ 
their utility in a language which is designed for efficient implementation, A 
brief note about the compiler is necessary. The compiler first breaks program 
text into "lexemes "--atomic symbols for operators, reserved words, and identi- 
fiers. The lexeme for an identifier is unique within its scope; hence, 

begin own b; begin own b; . . . end; end; 

causes the creation of two different lexemes for "b". 

A structure access may best be understood as a lexeme-stream macro 
substitution mechanism,* where the structure body defines the lexeme-stream 
(with dots preceding formals removed). At a structure access, the actual 
parameters are evaluated (code is produced for their evaluation) and the incar- 
nation actuals are retrieved. The compiler input is then taken from the struc- 
ture lexeme-stream with actuals substituted. 

Thus, under the array2 structure above, 

C[2,l] *- .C[3,5] +8 
will compile as if we had written 

(C+2*9+l) <- .(C+3*9+5) + 8 
which, because of compiler optimization will compile as if we had written 

(C+19) <- ,(04-32) +8 ^ 

which will generate three machine instructions! The code compiled for our 
example is included as an appendix. 

CONCLUSION 

Bliss factors the separate issues of allocating storage, binding names 
to addresses and structuring the storage referenced by a name. Although all 
allocating declarations also bind names to the referenced store, names may be 
bound to addresses dynamically via the bind declaration which presiraies the 
storage has been allocated for the contents of the named storage, A name may 
be structured using the map declaration independent of its allocation and 
binding. Because relationships often do exist between these three aspects of 
data structuring--allocating, binding and mapping--coramunication is allowed 
via "incarnation actuals", "size expressions" and "incarnation formals". 

Use of the mapping, allocating declarations in Bliss permits the ease 
of use of other higher-level language declarations; the factoring of the 
issues of allocation, binding and structuring helps to separate the activities 
of data structure programming and algorithmic progranming, while maintaining or, 
in fact, improving program efficiency* 



*Structures are sometimes more efficiently accessed as routines. The current 

(unsatisfactory) solution is to compile those structures with declarations 

(other than their formal parameters) as routines. -\ 
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APPENDIX 

o 

0001 BEGIN 

0002 

0003 % MUST BIND AN UPPER BOUND FOR MATRIX DIMENSION % 

0004 

0005 BIND N=150; 

0006 

0007 % STRUCTURE DECLARATIONS FOR B AND C % 

0010 

0011 STRUCTURE VECTOR [I] = .VECTOR+.I-l; 

0012 STRUCTURE UPPERDIAG[I,J] = [I* (I-l)/2] 

0013 .UPPERDIAGf ( . J-1) * ( . J-2) /2+/I-1; 
0014 

0015 GLOBAL THISN, ' 

0016 VECTOR B [N] , 

0017 UPPERDIAG C[N,N]; 
0020 

0021 % HERE WE VDULD BEGIN THE OUTER LOOP TO READ "THISN" (THE 

0022 , SIZE OF THIS ARRAY) AND THE CQEFFICIEJ/T MATRIX, "C" . 
0023 

0024 HERE WE WDUID BEGIN THE INNER LOOP TO READ THE CONSTANT 

0025 VECTOR, "B"* % 
0026 

0027 DEGR K FROM -THISN TO 2 DO 

0030 BEGIN 

0031 BIND VECTOR C0LUMNK=C[1, .K] ; 

0032 DECR I FROM -K-l TO 1 DO 

0033 B[.I]-H.B[.I]-.COLUMNK[.I]*.B[.K]; 

0034 END; 
0035 

0036 % HERE WE WDUID OUTPUT OR SAVE THE SOLUTIONS WHICH HAVE 

0037 BEEN lEBT IN "B". THEN WE WOUUD CONTINUE THE INNER AND 
0040 OUTER LOOPS. % 
0041 
0042 "BIHD; 



D 
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LINE 



OFFSET lABEL 



OPCODE- REGISTER,ADDRESS (INDEX REG) 





0000 




M3VE 


13,THISN 


0030 


0001 


L453: 


CAIGE 


13,2 




0002 




JRST 


$S,L460 


0031 


0003 




ADD 


$S, [000001,, 000001] 


0032 


0004 




MDVE 


04,13 




0005 




SUBI 


04,2 




0006 




MDVE 


05,13 




0007 




SUBI 


05,1 




0010 




IMUL 


04,5 




0011 




ASH 


04,-1 




0012 




HRRZI 


06,C-1(4) 




0013 




jyOVEM 


06,1($F) 




0014 




IXDVE 


14,13 




0015 




SUBI 


14,1 


0033 


0016 


L630: 


CAIGE 


14,1 




0017 




JRST 


$S,L503 


0034 


0020 




MJ7E 


07,14 




0021 




ADD 


07,1 ($F) 




0022 




MOVE 


10,B-1(13) 




0023 




IMJL 


10,-1(07) 




0024 




SUB 


10,B-1(14) 




0025 




M3VNM 


10,B-1(14) 




0026 




SQJA 


14,L630 Hi 




0027 


L503: 


SUB 


$S, [000001,, 000001] 


0035 


0030 




SQJA 


13,L453 iff 




0031 


L460: 


SETZ 


$V,0 



jJJXMj 



;LOCAL 



MODULE LENGTH =26+1 
COMPILATICN COMPLETE 



5-15 



D 



3 



D 



HELP. DOC 
C William A. Wulf 



D 



D 



BLISS DEBUGGING SUPPORT 

••••« VERSION TWO #••♦• 



WM, A, WULF 

APRIL 23, 1971 

MODIFIED 2 SEP 71 MG MANUGIAN 

INTRODUCTION 

DDT MAY BE USED TO DEBUG PROGRAMS WRITtEN IN BLISS, HOWEVERi 
THE USE OF DDT ALONE REQUIRES A FAIRLY DETAILED KNOWLEDGE OF THE 
RUN-TIME REPRESENTATION OF BLISS PROGRAMS (STRUCTURE OF 
THE STACK, ETC.) AND IS NOT ESPECIALLY CONVENIENT, IN 
PARTICULAR, DDT CANNOT EXPLOIT ANY SPECIAL INFORMATION ABOUT 
THE STRUCTURE OF THE OBJECT PROGRAM. THE SERIOUS BLISS PROGRAMMER 
IS WELL ADVISED TO LEARN THE BLISS RUN-TIME STRUCTURE — 
NEVERTHELESS, THERE ARE STILL A NUMBER OF DEBUGGING AIDS 
WHICH DDT DOES NOT PROVIDE*. IN ORDER TO IMPROVE THE SITUATION, 
A MODULE CALLED "HELP" HAS BEEN WRITTEN TO AUGMENT THE FACILITIES 
OF DDT. THIS MODULE MAY BE LOADED (ALONG WITH DDTJ WITH ANY 
BLISS PROGRAM -- ALTHOUGH RECOMPILATION OF HELP IS NECESSARY 
IF THE USER IS NOT USING THE STANDARD BLISS SYSTEM REGISTERS, 
"HELP" IS WRITTEN IN BLISS AND THEREFORE THE FACILITIESRIBED BELO 
BELOW MAY BE CALLED DIRECTLY FROM THE USERS SOURCE PROGRAM EVEN 
THOUGH THEY ARE PRIMARILY INTENDED FOR USE FROM DDT, 

HOW TO USE HELP 



1. THE ROUTINE(S) TO BE LOADED WITH HELP MUST CONTAIN THE 
TIMER SWITCH IN THE MODULC HEAD AND BE COMPILED WITH THE /T SWITCH*, 
WITHOUT /T THE TIMER SWITCH IS INGNORED DURING COMPILATION ANDi 
THEREFORE, MAY BE A PERMANENT PART OF A MODULE HEAD WITH NO HARM'. 

2. THE HELP MODULE MUST NOT BE COMPILED WITH /T, 

3. THE MODULE! TO BE DEBUGGED MUST BE LOADED WITH DOT AND HELP 

SUCH THAT DOT IS LOADED jUST ABOVE JOBDAT IN THE LOW SEGMENT, FOR EXAMPLEi 

.DEB FDD, HELP 
WORKS JUST FINE. 

4. NOTE THAT THE FIRIT FOUR WORDS OF EVERY ROUTINE ARE DEBUGGING 
OVERHEAD AND THAT ACTUAL CODE fOR THE ROUTtNE ITSELF STARTS AT THE 
FIFTH WORD. TO TRACE A CALL TO A PARTICULAR ROUTINEi A BREAKPOINT MUST 
BE INSERTED AFTER WORD 4 OTHERWISE THE NECCESSARY HOUSEKEEPING DONE 

BY THE FIRST FOUR WORDS OF TWi ROUTINE WILL NOT HAVE BEEN COMPLETED 
AND THE STACK WILL NOT BE SEt UP FOR PROPER TRACING', 

LIKEWISE THE (LAST-SIX)TH WORD TO tHC (LASt«ONE)TH WORD OF EACH ROUTINE 
ARE DEBUGGING OVERHEAD AND BREAKPONTS INSERTED IN THIS AREA 
WILL GIVE UNPREDICTABLE RE$ULT«, J^OTE THAT THERE ARE NO RESTRICTIONS 
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IN PLACING BREAKPOINTS IN ACtUAL CODE OUTSIDE Or THE DEBUCCINC 
PROLOG AND EPILOG, 

5. THE ROUTINE BPN IN HELP MUST BE MODIFIED FOR EACH NEW D 

VERSION OF DDT SINCE IT LOOKS AT THE DDT OBJECT CODE TO DETERMINE 

THE NUMBER OF THE LAST BREAKPOINT. IT IS CURRENTLY COMPATIBLE WITH 

DDT (VERSION 32» EDIT 23), 

THE ONLY SET OF DEBUGGING ROUTINES 

WHICH REQUIRE BPN IS THE XAREA(X) SET, THE OTHERS FUNCTION 

iNDEPENTLY OF BPN. 

TO MODIFY BPN APPROPRl ATELYi DO THE FOLLOWlNGi 

A. DETERMINE THE VALUE OF THE SYMBOLS 

BC0M3 
BIADR 

IN UODT BY LOADING DDT.REL FROM SYS AND TYPING 
THEIR VALUES! 

.LOA %S SYSIDDT 
LOADING 

LOADER NK CORE 

EXIT 

.DD 
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BC0M3»NNNN BlADRiMHMM 

B. INSERT THE TWO VALUES JUST TYPED INTO THE 
APPROPRIATE BINDS |N BPN IN THE SOURCE OF HELPiBLi; 

C. RECOMPILE HElP*.BLI 

OF COURSE, YOU MAY ALSO PATCH THE STANDARD VERSION OF HELP 
WITH DDT AFTER LOADING DDT, HELP, AND THE MODULE(S) TO BE DEBUGGED; 
CONSULT AN EXPANDEO(/M) LISTING OF HELP TO DETERMINE WHICH LOCATIONS 
IN CORE TO MODIFY, 



FACILITIES 



THE FEATURES CURRENTLY IMPLEMENTED ALLOW DISPLAY OF THE 
USER'S STACK, TRACING OF CALLS ON SPECIFIC ROUTINES, 
DISPLAY OF VARIABLES AND RRCtONS, AND AN EXTENSION OF THE 
ALT-MODE-X <$X) FEATURE OF DDT*. THESE FEATURES ARE PROVIDED 
BY A SET OF GLOBAL ROUTINES iN THE HELP MODULE! THESE ROUTINES 
ARE DESCRIBED IN DETAIL BELOW, 

THERE ARE THREE WAYS IN WHidH ONE OF THE ROUTINES JN HELP MAY ^ 

BE ENTERED! A DIRECT CALL fROM THE USERS PROGRAM, FROM A DDT 
CONDITIONAL BREAK-PQINT, OR BY EXECUTING A "PUSHJ" WITH THE 
DDT ALT-MODE-X FEATURE. THE READER IS PRESUMED TO BE FAMILIAR 
WITH THESE FEATURES OF DOT', 
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CONSIDER AN example;: "XSTAK" IS ONE Or tHE ROUTINES 
PROVIDED •- ITS EFFECT IS TO PRINT A DISPLAY Or THE 
USERS STACK, SHOWING THE ROUTINES CALLED, WHERE THEY WERE 
CALLED FROM, THEIR ACTUAL PARAMETERS, AND THEIR LOCAL VARIABLES, 
THE FORMAT OF THIS DISPLAY WILL BE DESCRIBED BELOW, NOW, 
SUPPOSE YOU HAVE A ROUTINE NAMED "THUD" AND YOU SET A DDT 
BREAKPOINT BY TYPING: 

THUD+25B 

AT SOME LATER TIME, WHEN YOUR PROGRAM IS RUNNING A CALL WILL 
BE MADE ON THuD. THE BREAKPOINT WILL OCCuRi AND DDT WILL 
TYPE? 

SNB>>THUD*2 

AT THIS POINT YOU MAY DISPLAY THE CURRENT STACK BY USING 
"XSTAK" AND ENTERING IT VIA THE $X FEATURE •»• IE. TYPE* 

PUSHJ SREG,XSTAK$X 

(BE SURE TO USE THE PROPER VALUE FOR "SREG" •• NORMALLY 
IT'S 0.) AFTER THE DISPLAY IS FINISHED YOU'LL BE BACK 
IN ODT AND MAY PROCEED VIA AN $P, OR DO WHATEVER ELSE 
SUITS YOUR FANCY, 

AN ALTERNATIVE TO THE EXAMPLE ABOVE IS tO USE THE 
CONDITIONAL BREAKPOINT FEATURE OF DDT. FOR EXAMPLE* SUPPOSE 
YOU SET BREAKPOINT #1 AT THUD BY TYPING 

THUD+2$1B 

AND SET THE CONDITIONAL BREAKPOINT INSTRUCTION AT SlB*i 
TO THE SAME OLD PUSHJ! 

$18+1/ XXXX PUSHJ SREG,XStAK 

NOW, AS SOON AS THE CALL ON tHUD IS MADE THE StACK WILL 
AUTOMATICALLY GET THE STACK DISPLAY •• THEN THE BREAKPOINT WILL 
OCCUR. THIS MODE OF USING HELP IS MORE USEFUL WITH SOME 
OF THE OTHER HELP ROUTINES TO BE DESCRIBED BELOW, 

ALL OF THE GLOBAL ROUTINES !N HELP HAVE NAMES OF THE 
FORM: 





X2EZZ 


OR 


X2Z2ZC 


OR 


XZZ2ZB 


OR 


xnup 



THAT IS, THEY ALL START WitH THE LETTER "X" FOLLOWED 

BY A FOUR CHARACTER NEMONlCi FOLLOWED BY A BLANK, A "C", 

A ♦'B", OR A "P". ROUTINES WJtH A COMMON 
,-- W222Z" ALL PERFORM THE SAME ^UNCTlONj THE SUFFIX DETERMINES 
l^, WHAT HAPPENS AFTER THE FUNCTION IS COMPLCtE". IN PARTICULAR 

THE FOLLOWING TABLE SUMMERJlES THE MEANING OF tHE VARIOUS 

SUFFIX LETTERS: 



SUmX MEANING 

BLANK .IF CALLED FROM A USER PROSRAMi SIMPLY 

RETURN AND PROCEED AS USUAL, "^ 

«ir CALLED BY SX, RETURN TO DDT -^ 

to PERMIT USER TO DO HIS THING, 

• If CALLED FROM COND*. BREAKPOINT, TREAT 

AS A »»!»» SUFFIX (SEE BELOW), 

C .FOR CONDITIONAL BREAKPOINT ONLYi 

AFTER COMPLETING FUNCTION CAUSE 
DOT to DECREASE ITS PROCEED 
COUNT AND POSSIBLY BREAK. 

B FOR CONDITIONAL BREAKPOINT ONLY, 

AFTER COMPLETING FUNCTION FORCE 
A BREAK, 

P FOR CONDITIONAL BREAKPOINT ONLY, 

AFTER COMPLETINF FUNCTION FORBE 
PROGRAM TO PROCEED (LIKE AN SP). 



THE GLOBAL ROUTINES PROVfOCD IN THIS RELEASE , AND THEIR 
FUNCTIONS, ARE SUMMERIHED JN THE FOLLOWING TABLEl 



ROUTINE FUNCTION J) 

XSTAK DISPLAY THE USERS STACK IN THE FORMi 
XST AKC 

XSTAKB A (- 0*13) 110, ,0 2l0,il356 

XSTAKP 110, il3 211702, ,X*1 

B (•. C*25> 

t <* 0*44) llli.l 

ETC. 

THE NAMES JN THE LEFT COLUMN ARE THOSE OF THE 

VARIOUS ROUTINES CALLED, ON THE SAME LINE IN THE 

LOCATION FROM WHICH THE ROUTINE WAS CALLEDi 

EC. 'M- G*25)"i AND THE ACTUAL PARAMETERS 

DISPLAYED tN HALF-WORD OCTAL FORMAT", ON THE 

LINES BELOW THE CALL ARE THE VALUES OF THE 

LOCAL VARIABLES OF THE ROUTINE^ NOTE THAT 

THE ACTUALS AND LOCALS ARE iNDlCATED BY 

POSITION • NOT NAME*, ALSOj BE CAREFUL • SOME 

LOCALS ARE AUTOMATICALLY GENERATED BY THE 

COMPILER •• SO THE POSITION MAY NOT EXACTLY 

CORRESPOND WITH ITS DECLARATION POSITION, -^. 

THE LOCAL POSITIONS DO CORRESPOND WITH J 

THOSE SHOWN iN THE "/M" LtSTiNO GENERATED 

BY THE COMPILER. THE INITIAL ROUTINE EXECUTED 

HAS A NULl CALLER'. 



XCALL 
XCALLC 
XCALLB 
XCALLP 



XAREA 

XAREAC 
XAREAB 
XAREAB 
XAREAP 



THESE ROUTINES DISPLAY, IN A FORMAT LIKE THAT 
ABOVE THE MOST RECENT ROUTINE CALLi ONE USEFUL 
APPLICATION OF THESE ROUTINES IS THAT 
OF TRACING THE EXECUTION OF ONE 
PARTICULAR ROUTINE'. BY PLACING A CONDITIONAL 
BREAKPOINT AT THE HEAD OF THE ROUTINE TO BE 
TRACED AND A "PUSHJ SREG, XCALLP" IN THE 
APPROPRIATE COND«BP LOCATION A TRACE OF THE 
ROUTINE WITH ITS ACTUALS WILL BE OBTAINED, 

THESE ROUTINES DISPLAY A NUMBER (CURRENTLY e) 

OF CONTIGUOUS AREAS OF MEMORY IN HALF WORD 

OCTAL FORMAT'. 

THE AREAS TO BE DISPLAYED ARE DEFINED 

BY NINE TABLES CALLED XAREA0I XAREAl,,.., 

XAREA9. EACH OF THESE TABLES IS EIGHT WORDS 

LONG • THE FORMAT OF EACH WORD IN THESE 

TABLES ISI 



SIi!E 



BASE 



C 



XALTX 



IF ONE OF THESE ROUTINES IS ENTERED FROM 
CONDITIONAL BREAKPOINT #Ni THEN THEY WILL 
PRINT THE REGIONS DESCRIBED BY THE TABLE 
" X A R E A N " * 

IF, FOR EXAMPLEi YOU WANT TO DISPLAY 
A FIVE-WORD REGION WHOSE BASE ADDRESS IS 
"CLOP" EVERY TIME THE ROUTINE "THUD" IS 
CALLED YOU MIGHT TYPEI 



THUOi^SSiB 
$1B*1/ XXXX 
XAREAl/ XXXX 



PUSHJ SREGiXAREAP 

5i,CL0P 



THEN SIT BACK AND WATCH. 
THIS ROUTINE IS A GENERALI2 
THE "SX»» FEATURE OF DDT IN 
IT PROVIDES AN INTERFACE BE 
ROUTINE WRITTEN IN BLISS; 
ALL THE MESSY DETAILS OF SA 
ETC.. NECESSARY TO GET FROM 
BLISS ROUTINE AND BACK AGAl 
THINGS ALONG THE WAY'. THE 
BLISS ROUTINE TO BE CALLED 
THE CONTENTS Of ONE OF THE 
XALTXl,.'.,,XALtX8; IF XALtX 
CONDITIONAL BREAKPOINT #N ( 
OR EXPLICIT "$X" CALL) THEN 
CONTENTS or XALTXN WILL BE 
THE ROUTINE tO BE CALLED, 



ATION OF 
THE SENSE THAT 
TWEEN DDT AND ANY 
IT WORRIES ABOUT 
VINC REGlSTERSi 

DDt INTO A 
N WITHOUT DESTROYING 
ADDRESS OF THE 
IS SPECIFIED BY 
WOROSI XALTX0, 

IS CALLED FROM 
Ni0 IF DIRECT 

THE 
USED TO SPECIFY 



THE ROUTINE CALLED INDIRECTLY THROUGH 
XALTX IS EXPECTED TO RETURN A VALUE OF 0,1, 
• THESE VALUES ARE INTERPRETED LIKE THE 
CB.AND P IUFF!XS RESPECTIVELY; 
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CONCLUSION 

3 

THE FACILITIES DESCRIBED ABOVE ARE A PRELIMINARY SET 
WHICH WILL BE EXPANDED IN THE rUTURE'. I HOPEi NAY EXPECT, 
USERS OF HELP TO SUGGEST ADDITIONAL AND/OR REVISED 
FEATURES. 



J 



D 



6-6 



HELP.BLI 
William A. Wulf 



3 



O 



D 



MOnULE help« 
9EGIN 



I HELPER 

I •••*« VERSION TWO ••«#<» 



I THIS MODULE CONTAINS SEVEP?aL ROUTINES WHICH MAY BE LOADED WITH 

I A NORMAL BLISS MODULE TO PROVIDE DEBUGGING SUPPORT --IT 

I PRESUMES THAT »CDT» IS ALSO LOADED^ 
I 

EXTERNAL DDTEND ,DDT , JOBSYM, JDbRELi JOBHRLl 

3IVD BUFFLENGTHslSl 

OW.M RUrrCBUFFLENGTH]! 

aWN^PBUFFl ! POINTER INTO THE OUTPUT BUFF 

MACRO EBUFF8 ( BUFF*BUFFlENGTH )5 . 
BBUFF" BUFF<36,7>$, 

SAVREGS* REGISTER IlI^lSjDo PUSH(SREGi0i I) WHIlE(I-.I-I) GTR ^i^t 
RESREGS* I--15|D0 P0P<SREG. #20 , I ) WHILE ( I -. I ♦DlSS 0I$i 
SUBRET(LiV)« IF . ( L)<0. 18>LSS< DDTEND AN0#777777) THEN 

(L)*.(L)*(V)|$» 
ENTER" SAVREGSjS, 
LEAVE(LLiVV)« RESREGSI SuBRET(LLiVV)I .VREG $1 

MACHCP PUSH»#261i P0P«#262> 
9IMD AREAS2«8i NUMAREASaBI 

STRUCTURE SaTLI.J] i n#J] < . SaT* . I*AREaSH* . J><0»36> J 
5LPBAL XAREA0»XAREAllXAREA2tXAREA3l 

XAREA4|XaREA5IXAREA6IXAREA7I 

XAREA8CAREASZ3I 
BIK'D Sat XaREAS « XAREA0I 

CLCBAL XALTX0iXALTX1.XALTX2,XALTX3. 
XALTX4,XALTX5iXALTX6,XALTX7i 
XALTX8I 



FORWARD FIXFI 

GLOBAL ROUTINE TiMERa 

(FlXF<#l40i,JOBREL<0il8>)» FIXF ( #400010, , jOBHRL<0i 18> > I ) > 

iFix UP The stack the way help expects it to BE, 

tI.E,, INSURE THAT THE FREG IS PROPERLY PUSHED ONTO THE 
tSTACK AT THE BEGININC AND POPPEO OFF AT THE END OF EVERY 
iRflUTINE AS IT WAS JN THE GOOD OLD DAYS, 

ROUTINE FIXF(STaRTiFINISH)» 
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BEGIN 

BIND F«FREG<0,0>, S«SRE:r,<0i 0>; 

MACRO MACHWORDCOP,ACiAD)s 0Pt27*AC»23*AD$ , 

PUSHSr«MACHW0RD{*26l,S,F)$, 
PUSHS12»MACHW0R0< #261,01 #12)$, 
P0PSF«MACHW0RD(#262iS,F)S, 
HRR2FS«MACMWORr)(#550,F,S)$. 
JRSTHPL2»MACHW0RD( #254,0, ,I*2)$, 
JRSTHPL4«MACHW0RD( #254,0,, I*4)$, 
JRSTHPL5«MACHW3RD( #254,0. ,I*4)$, 
JRSTHPL6bmACHWORD(#254,0, ,I*5>$I 

MACHOP CAULla#1347, JRSTa#254| 
REGISTER RJ 



D 



BIND SETUWP«#36; 

R<i0| 

CAlLl (RiSETUWP)i 
JRST (4,0)1 



ITURN OFF HIGH SEG WRiTE PROTECT 
!HALT ON SETUWP ERROR 



INCR I FROM .START TO 
IF ,C»I)<18,18> EQL 



iFlNlSH - 11 
#551t9*#l2t5 
.(•I*4)<27i9> EQL #265 



DO 

AND »Ci»I*l). 

XJSPX 



EQl PUSHS12 



THEN IF 
THEN 
BEGIN 

(•n<0,36>i.jRSTHPL4J 

UNTIL ■,(•1X18, 18> EQL #561*9*#12t5 DO l«-,I^lj 

IF #(Pi*l) EQl PUSHS12 

THEN (»I-l)<0i36>*'jRSTHPL6l 
END 
ELSE 
BEGIN 

(Pn<0;36>*jRSTHPL2l 
(PI*2)<0,36>*PUSHSFI 
(#I*3)<0,36>*HRR2FSI 

UNTIL V(i^n<l8.l8> EOL #56lt9*#12t5 DO I*-!!*!) 
IF •(•!♦!) EOl PUSHS12 
THEN 

Begin 

(•I-1)<0.36>*'JRSTHPl5| 
(PI*4)<0,36>*POPSFI 

END 
END 



D 



ENDI 



ROUTINE F50T6(X)i 



.X EQL THEN ELSE 

,X LEO #12 THEN ,X*#17 ELSE 

.X LEO #44 THEN ,X*#26 ELSE 

,X EQL #45 THEN #16 ELSE 

,X EQL #46 THEN #04 ELSE #051 



D 
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ROUTINE B50T6(X)i 

molH REGISTER RI 
^••.X AND #377777777771 R^-gi 
OECR I FROM 5 To DO 
C <R-.Rt(-6)l R<30.6>-B"50T6<,X MOO #50)| X«-.X DiV #50); 

ENDJ 

ROUTINE BPN» 

\ THIS ROUTINE MUST 3E CMaNGED FOR EACH VERSION OF DDT •. 

\ OR, BETTER YET, DDT SHOULD BE CHANGED TO MAKE THE MOST 

! RECENT BREAK POINT NUMBER AVAILABLE. 

BEGIN BIND BC0M3«#l5S6, B1AdRp#3627I 

(((»BC0m3-1) and #777777)-(B1ADR*3))/3 

ENDI 

ROUTINE SDDTST(x)« 

BEGIN REGISTER R,NI OWN HNi2HI HZ«-HN,.0| 
P^.jOBSYM^li N-2HI 
WHILE (R*'.R*#2e00002) LSS DO 
IF (»»R-.X) LEO THEN 

IF (»^R-»»N) GEO THEN N«*.R| 
.N*l 
ENDI 

ROUTINE DuMP» 

BEGIN MaCHOP CALLI«#47I ^eGISTER Rj 
R««BUFFI CALLICR,*3>| R^-BUF^LENGTHI 
00 BUFFC,R3«.0 KHILE tR«-,R-l) GIQ 0| 
PBUFF^-BBUFF 

C ^^^^ 

ROUTINE INITHEIP* <BUFF4.0| DUMP())I 

ROUTINE PUT<X):» 

IF .X NEQ THEN 
BEGIN 

IF .PBUFF EQL THEN "iNlTHELPO ELSE 
IF , PBUFF GEO EbuFF THEn DUMPOI 
REPLACEUPBUFFi.X) 
ENDi 

ROUTINE PUTS<X)« 

WHILE ,X NEQ DO <PUT( . X<28, 7>) I X-.X»7)| 

ROUTINE CRlFi <PUT(#15)J PUT(#l2)l DUMPOJl 
ROUTINE TaB« PUT(#li)| 

ROUTINE PRlNTdCXJ" 
BEGIN LOCAL LI 
DECR I FROM 5 TO DO 

<L*.X<30,6>| X^.X^ei jF ,L NEQ THEN PUT{ .L*#40> > | 
ENOJ 



C 



ROUTINE PRINT50(X)» PRlNT6«B50T6( , X) ) ; 

ROUTINE PM0C(X)8 

BEGIN LOCAL Tl T*0l 
DECR I FROM 11 TO 1 DO 
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IF .X<3#,I,3> Neq C5 ThEn EXITLnOP (T-,I)J 
TECR I FROM ,T TO nO PUT ( "0"* . X<3* . I , 3> > I 

^OjTINE PDISP(X,T)s ^ 

IF .X<0,18> LSS (DDTEND AND tllllll) THEN PMOC ( . V<55 , 18> ) ELSE 
REGIN LOCAL L; 

L*-50DTST( .X<0,18>); PR I NT5i2 ( (5>(?L ) I 
!F ,T AND (L*»^(«»L*1)*.X<0i18>> GTR THEN 

(PUT{"*'Ml PMOC<.L))l 
FNnj 

ROUTINF SPN(N)s INCR I FROM 1 To ,M DO PUT(" ")J 

ROijTiNE P2Cs (PUT(",")J PUTC',"))! 

ROUTINE SP3s SPN(3) I 

ROUTINE PWD(X)s (PM0C(.X<18.1,8>); P2C(); PD I SP ( , X<0 , 18> , 1 ) ) I 

ROUTINE PWD2(X)alF ,X GEQ TH^N P-iQCX) ELSE ( PUT ( "-'O I PMOC ( - . X ) ) I 

ROUTINE PW0(X)3 CPMOC( .X<18,18>> ; P2COj PMQC ( . X<0, 18> ) ) J 

ROUTINE PRGcBASEiF,T)s 

INCR I FROM ,F TO .T DO 
BEGIN 

PMOC(.I)l PUTSC"! 'Ml PWD2(SD(iBASE*.I-l)) J SPN(4)J 
IF NOT .1 THEN (CRLFO J TAB()) J 
ENDj 

ROUTINE PRC(F,CALLED)s 

BEGIN LOCAL NP ,LP » CaLLER I 

CALLER*'. ( ,F-l)<0,18>;,ll 

MP*- IF , (9i(,F-in<27,9> NEO #274 THEN ELSE 

IF , (e»(.F-l)-2)<27i9> NEQ #261 THEN ELSE 

.(<^eB( .F-.1))<0^18>; 
LP*- .F-l-'.Npl 

PDISP(iCALLEDi0)l TAROj PUTSCM*"); IF .CALLER MEQ -1 
THEN PDISP( .CALLER*!) I PUTC")")! 
TABOl PRG« .LP»1» .MP) I 
.CALLER<0il8>*fNPtl8 
ENOI 

ROUTINE PSTKc 

REGIN LOCAL F , CALLED, VAL , LL . NLl 

VAL«-iVREGl F*>®»FREG| NL*'^ i FREG« , F-2 J LL^-iF*!! 

CALLED*-. (<!»(.F.1)-1)<0,18>| CRLFOI 

UNTIL •CALLE0<eil8> EQL #777777 DO 

BEGIN LL^'.F"*!! CRLFOi 

CALLED-PRC(.F,.CALLED<0.ie>)l CRlFOI TABOi pRG ( , LL . li . NL n 

^JL*'(3>F-?SlF-.CALLE0<18,l8>-2^ 

F^-ebipF J 

ENDj 
.VAL ~\ 

cNni -^ 

ROUTINE PFRC = (LOCAL F| CRLFOi F«"9<P>^FREG; PRC ( ,F , , ( e>( , F-l) d )<(3 , 18> ) ) I 

ROUTINE PAREAs 
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f^EGIN LOCAL 

INCR I FROM 

BEGIN 9 

CRLFO 

IF AREA 



J,K,N,BNl BN-bPN()ICRLF(); 
M TO AREAS?"! 00 
BIND AREAs.'xARfASC.BN, .I3<0,18>; 
I J^-.XAREasC.BM, iI]<18,l8>jN«*0| 

A NEC Then 



., ...... .-^- Then 

DO(CRLF(nPDISP(ARE.At:.Ni],l) jPUTCV") JTABOI PwD2 ( ?'AReAC , N] ) ) 
E (N*..N + t I J*.. J-1) GTR 01 



FNDJ 



END 



WHILE CN-.N + lj J*-,J-1) GTR 01 



5L:5BaL routine XSTAK(X)s(ENTERI PSTKOj LEAVE(X*1,1)) J 
GL'^BAL ROUTINE XSTAKC( X ) s ( ENTER I PSTKOj LEAVE ( X*1 , ) ) I 

PSTKOI LEAVE(X*1,1) )I 

pstkOi leave(x*i,2)); 



GLtlBAL 
GL'^BAL 



ROUTINE 
ROUTINE 



xstak8(X)x(enteR; 

XSTAKP(X)a(ENTERj 



SL^BAL ROUTINE XCALL ( X ) = (ENTER I PFRCOl LE A vE ( X*l , 1 > ) I 
GLOBAL ROUTINE XCALLC(X ) a ( ENTER; PFRcOJ LEAVE U*! , 0) ) ^ 
(5L^BAL ROUTINE XCALLB ( X ) s ( ENTER J PFRCOJ LEAVE ( X*l , 1 )) j 
GLOBAL ROUTINE XCALLPC X ) = ( ENTER J PFRCOJ LEAVE ( X + 1 , 2 ) ) J 



GLOBAL ROUTINE XAREA ( X ) = (ENTER I PAREAO; LEAVE ( X^l , 1 ) ) I 
GLOBAL ROUTINE XAREaC ( X ) a ( ENTER J PAREAOj LEA VE ( X*1 , J? ) ) i 
GLOBAL ROUTINE XAREaB(X), (ENTER; PaREAOj LEAVE ( X*! , 1) ) ; 
GLOBAL ROUTINE XARE AP ( X )=( ENTER ; PAREAO; LEAVE ( X*l , 2 ) ) J 



GLOBAL ROUTINE XALTX (X ) s (LOCAL L; ENTER; L*' (v«XALTX0C9PN ()])() ; 
LEAVE(X*1,,L)); 



ENn 
ELUDHM 
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00100 BLISS TIMER MODULE--^-- 

00200 

00300 THE BUSS TIMER MODULE CONSISTS Or A SET OF ROUTINES 

r 00400 WHICH ENABLE THE USER TO GATHER TIMING STATISTICS ON BLISS 

^ 00500 PROGRAMS DURING execution; THE TIMING SYSTEM CONSISTS OF 

00600 THE BLISS MODULE "TIMER" AND THE MACRO-10 MODULE "TIMINT"', 

00700 

008N IN ORDER FOR THE tlMlNG ROUTINES TO FUNCTlONi THE TfMCR 

00900 ROUTINES AND THE SYSTEM TO BE MONITORED MUST BE LOADED WITH 

01000 DOT (THE /D SWITCH TO THE LOADER, %D SWITCH TO CCL» OR THE 

01100 DEBUG COMMAND ALL ACCOMPLISH THIS)'. ASSUMING THE USER 

01200 WISHES TO MODIFY ANb RECOMPILE HIS MAIN PROGRAM (A WAY fO 

01300 AVOID THIS IS DISCUSSED BELOW), HE MUST ADDl 
01400 

01500 EXTERNAL Tl MSEt i T IMENO ; 

01600 

01700 TO HIS DECLARATIONS, AND THE CALLS IN tHIS MANNERI 

01800 

01900 < BEGINNING OF MAIN PROGRAM > 

02000 

02100 TIMSETOi 

02200 

02300 < MAIN BODY OF MAIN PROGRAM > 

02400 

02500 TlMENDOl' 

02600 

02700 < END OF MAIN PROGRAM > 

02800 

02900 
r 03000 THE <3EGlNNiNG> MAY INCLUDE STACK INITIALIZATION IF NOT 

^ 03100 DONE IMPLICITLY BY THE STACK DECLARATION IN THE MODULE HEAD, 

03200 PLUS ANY PROCESSING THE USER WISHES TO DO BEFORE TIMING 

03300 BEGINS. ALL CODE EXECUTED BETWEEN TtMSETO AND TIMENDO 

03400 WILL BE MONITORED*. THE <END> MAY CONTAIN ANY OTHER 

03500 PROCESSING, IN PARTiCULARi THE <END> MAY CONTAIN CALLS ON 

03600 THE OUTPUT ROUTINES DISCUSSED BELOW'. 
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03100 TIMING OU T P UT 

00200 

00300 ^ 

00400 THE COLLECTED STATISTICS ARE SORTED BY THE REPORTING 

00500 ROUTINES AND OUTPUT IN THE FOLLOWING FORMATi 

00600 

007?)0 LOST TIME ««««»«•• a ftftftX 

00600 

00900 METERED TIME ♦♦♦#♦### « *«ftX 

01000 

01100 TOTAL TIME *«♦»♦»#» s 100% 

01200 

01300 OVERHEAD RATIO »»#<»X 

01400 

01500 DEPTH OF CALLS #»»»## 

01600 

01700 STACK LEFT »•♦*»»# 

01800 

01900 TOTAL RTNS »»»#*#♦# 

02002 

02100 TOTAL CALLS »♦»»»#### 

02200 

02300 NAME ---CALLS--- ---ROUTINE*-- -CUMULATIVE- RTN AVG CUM AVr, 

02400 AAAAAA »»«»»♦«# ••«% *•••••*• »«#J{ «#«««•« ♦♦#% *#••*••« «•#«•##* 

02500 

02600 

02700 "LOST TIME" IS THE PERCENTAGE OF TOTAL EXECUTION TIME 

02800 THAT WAS SPENT ACCUMULATING STATISTICS, THIS IS PROVIDED 

02900 FOR INFORMATION ONLYl IT DOES NOT INDICATE THAT THE ACTUAL 

03000 FIGURES HAVE AN ERROR INTRODUCED BY THE FACT THE ROUTINES 

03100 HAVE BEEN TIMED. 

03200 

03300 "METERED TIME" IS THE ACTUAL TIME SPENT IN EXECUTING THE 

03400 USER'S CODE, 

03500 

03600 "TOTAL TIME" IS THE SUM OF THE TWO ABOVE TIMES AND !S 

03700 THE TOTAL EXECUTION TIME OF THE PROGRAM BEING MEASURED* FROM 

03800 THE RETURN FROM TIMSeT{) TO THE CALL ON TIMENDO. 

03900 

04000 "OVERHEAD RATIO" IS THE PERCENTAGE BY WHICH EXECUTION 

04100 TIME INCREASED AS A RESULT OF THE SYSTEM BEING TIMED', THIS 

04200 IS THE COST OF MAKING THE MEASUREMENTS'. 

04300 

04400 "DEPTH OF CALLS" IS THE MAXIMUM DEPTH TO WHICH CALLS 

04500 WERE DYNAMICALLY NESTED, 

04600 

04700 "STACK LEFT" IS THE MINIMUM NUMBER OF WORDS 

04800 (APPROXIMATELY) LEFT AT THE TOP OF THE STACK AT THE DEEPEST 

04900 CALL. TO COMPUTE THE MAXIMUM DEPTH OF THE STACKi SUBTRACT 

05000 THIS VALUE FROM YOUR STACK SHE, 

05100 

05200 "TOTAL CALLS" IS THE TOTAL NUMBER OF ROUTINE ENTRIES 

05300 PERFORMED. 

05400 ^ 

05500 THE REMAINING FIGURES COME OUT TABULATED IN COLUMNS. AS ^ 

05600 follows: 

05700 

05800 

05900 THE "NAME" COLUMN CONTAINS THE NAME OF THE BlISS ROUTINE 

06000 OR FUNCTION. . . 

0^2 



06100 

06200 THE "CALLS" CQLUMN CONTAINS TWO FIGURESi THE NUMBER OF 
06300 TIMES THE ROUTINE WAS CALLED. AND THE PERCENTAGE OF THE 
( 06400 TOTAL CALLS WHICH THIS CONSTITUTED. 
06500 

06600 THE "ROUTINE" COLUMN CONTAINS TWO FIGURESi THE TOTAL 

0670J2I AMOUNT OF TIME SPENT IN THE RQUTlNEi EXCLUSIVE OF ITS 

06802h SUBROUTINES AND THE PERCENTAGE OF THE TOTAL METERED TIME 

06900 WHICH THIS CONSTiTUTED'. 
07000 

07100 THE "CUMULATIVE" COLUMN CONTAINS TWO FIGURESI THE TOTAL 

07200 AMOUNT OF TIME SPENT IN THE ROUTINE. I^'CLUDING ALL ITS 

07300 SUBROUTINES (WHICH MAY INCLUDE ITSELF), AND THE PERCENTAGE 

07400 OF TOTAL METERED TIME WHICH THIS CONSTITUTED, 

07500 

07600 THE "RT^ AVG" TIME IS THE ROUTINE TIME DIVIDED BY THE 

07700 NUMBER OF CALLS; THE "CUM AVG" TIME IS THE CUMULATIVE TIME 

07800 DIVIDED BY THE NUMBER OF CALLS, 

07900 

08000 ALL TIMES GIVEN ARE IN "TICKS", WHERE A TICK IS i0 

08100 MICROSECONDS, 

08200 

08300 THE OUTPUT MAY BE SORTED IN ANY OF THE AVAILABLE FIGURES 

08400 STORED BY THE TIMESORTO ROUTlNEl HOWEVER, SEVERAL SORTS ARE 

08500 PRE-SPECIFIED AND INCLUDE OUTPUTTING OF THE SORTED DATA'. 

08600 THESE are: 

08700 

08800 TIMSTl SORTED BY NAMES, ASCENDING, 

06900 

09000 TIM3T2 SORTED BY TOTAL CALLS, DESCENDING, 

09100 

09200 TIMST3 SORTED BY ROUTINE TIMES, DESCENDING, 

09300 

09400 TIMST4 SORTED BY CUMULATIVE TIMES, DESCENDING, 

09500 

09600 TIMST5 SORTED BY AVERAGE ROUTINE TIME, DESCENDING*, 

09700 

09800 TIMST6 SORTED BY AVERAGE CUMULATIVE TImES, 

09900 DESCENDING*, 

10000 

10100 TIMST7 SORTED BY ADDRESSES, ASCENDING, 

10200 

10300 ALTHOUGH TIMST7 DOES NOT APPEAR OBVIOUSLY USEFUL, 

10400 CONSIDER THE PROBLEM OF FINDING OUT WHICH MEMORY AREAS ARE 

10500 MOST HIGHLY ACCESSED IN A SYSTEM RUNNING ON A PAGED MACHINE*, 

10600 

10700 THESE ROUTINES MAY BE CALLED FROM THE USER'S MAIN 

10800 PROGRAM BY DECLARING THEM "EXTERNAL", OR FROM DDT (SEE 

10900 BELOW), 

11000 

11100 THE COLUMN ON WHICH THE OUTPUT IS SORTED IS INDICATED BY 

11200 AN ASTERISK ABOVE THE COLUMN. NOTE THAT THE NUMBER OF THE 

11300 SORT (1-6) CORRESPONDS TO THE COLUMN POSITION OF THE DATA 

11400 SORTED. 

11500 

11600 IN ADDITION TO THESE REPORTING ROUTINES, A ROUTINE 

11700 "TIMALLO" IS AVAILABLE WHICH CALLS ALL THE TIMING REPORTS 

11800 (TIMST1-TIMST7) AS WELL AS THE LOCALIZATION REPORTS 

11900 (TIMST8-TIMST9 CSEE BEL0W3). 
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00100 

00200 

00300 

00400 

00500 

0060k; 

00700- 

00800 

00900 

01000 
01100 
•01200. 
01300 
01400 
0150<^ 
01600 
01700 
01800 
01900 
02000 
02100 
02200 
02300 



----•LINE PRINT ER-*--* 



OUTPUT MAY BE DIRECTED TO THE LINE PRINTER BY CALLING 
THE ROUTINE "TIMLPTU"', ALL FURTHER OUTPUT NILL BE DIRECTED 
TO THE LINE PRINTER CLPT) UNTIL REDIRECTED TO THE TTY BY A 
CALL TO ''TIMTTYO". TIHLPTO SHOULD NOT BE CALLED UNTIL 
AFTER TiMEiNDO IS CALLED, THESE TWO ROUTINES MAY ALSO BE 
CALLED FROM DDT. 

ALL I/O IN THE USER'S PROGRAM SHOULD BE CORRECTLY 
TERMINATED, SINCE A »»CALL CSIXBIT /RESET/T' UUO IS EXECUTED 
PRIOR TO EACH PRINTING, NOTE THIS ALSO RESETS JOBFF TO 
,J0BSA<18,18> AND SETS THE WRITE^PROTECT BIT IN THE HIGH 
SEGMENT, IF ANY QF THESE HAVE AN ADVERSE EFFECT ON THE 
PROGRAM OR DATA BASE, THEN PRINTER OUTPUT MAY NOT BE USED, 



IF SPOOLING IS 
SEPARATE listing; 



IN OPERATION, EACH SET OF STATISTICS IS A 



THE CHANNEL USED FOR LPT OUTPUT IS 
IN THE BEGINNING OF THE PROGRAM, IT 
USER CSEE! STANDARD MODIFICATIONS)'. 



SPECIFIED BY A MACRO 
MAY BE CHANGED BY THE 
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055100 

00200 

00300 

00400 

00500 

0060^ 

0070,0 

00800^, 

00900 

01000 

01100 

01200 

01300 

01400 

01500 

01600 

01700 

01800 

01900 

02000 

02100 

02200 

02300 

02400 

02500 

02600 

02700 

02800 

02900 

03000 

03100 

03200 

03300 

03400 

03500 

03600 

03700 

03800 

03903 

04000 



---STANDARD MODIFICATIONS 



AS " 

HOME 

SMAL 

RUNN 

OUTP 

ARE 

"MAX 

IT 

ROUT 

PRIN 

"MAX 

THE 

ROUT 

TRAC 

STAC 



THE TIME 
OWN" STRU 
NT MAY N 
L (OR EVE 
ING BECAU 
UT INDICA 
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CURRENTLY 
INES ARE 
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RTN" MUST 
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AREAS ARE T 
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R OF ROUTINE 
T TO "200" 
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ACK 
ES T 
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TA AREAS 
AT THE 
Y BE TOO 
S WHILE 
WILL BE 
RAMETERS 
PROGRAMj 
D (E.G; . 
"MAXRTN" 
WILL BE 
VALUE OF 

ompiled; 

TO WHICH 
TO KEEP 
OF THIS 



IF DECLARED REGISTERS OR RESERVED REGISTERS ARE USED BY 
THE SYSTEM BEING TIMED, THEN THE MODULE HEAD OF THE TIMER 
MODULE MUST BE ALTERED AND THE MODULE RECOMPILED. 

IF THE SYSTEM BEING TESTED IS BEING LOADED WITH A HIGH 
SEGMENT ADDRESS OTHER THAN #400000, THE MACRO "HISEGAD" MUST 
BE CHANGED TO REFLECT THIS". 

IF THE LOCALIZATION MEASURES ARE DESIRED FOR BLOCKS OF 
MEMORY OTHER THAN 1024 WORDS IN SI2E (NO LESS THAN THIS, 
HOWEVER), THE MACRO "COREBLOCK" MUST BE CHANGED TO REFLECT 
THIS, THE VALUE OF COREBLOCK IS N FOR A BLOCK OF SIZE 2»»N 
(E.G,, 1024= 2«*10, SO COREBLOCK«10)". 

THE CHANNEL NUMBER USED FOR LPT OUTPUT IS #16, THIS IS 
TO PREVENT CONFLICTS WITH THE DDT raTCH FILE I/O WHICH USES 
CHANNEL NUMBER #l7', IF IT IS DEStRED TO CHANGE THIS 
ASSIGNMENT, CHANCE THE MACRO "LPTCHNL" IN THE BEGINNING OF 
THE MODULE AND RECOMPILE', 
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00100 
00200 
00303 
00400 
00500 

00600 

00700 
00800 
00900 

01000 



"-NONSTANDARD MOOIFICATIONS- 



IF THE DEFAULT VALUES OF FREGi SREGi AND VREG ARE NOT 
USED» THEN THE MODULE HEAD OF THE TIMER MODULE MUST 9E 
CHANGED TO REFLECT THISi AND THE TIMEP MODULE RECOMPILED'. 
IN ADDITION, THE DECLARATIONS IN THE MACRO-10 MODULE 
"TIMINT" MUST BE CHANGED TO REFLECT THE NEW VALUES, AND THIS 
MODULE REASSEMBLED', 



D 
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00100 
00200 
00300 
00400 
0^)500 
00600 
00700 
0081^19 
00900 
0X000 
01100 
01200 
01300 
01400 
01500 
01600 
01700 
01800 
01900 
02000 
02100 
02200 
02300 
02400 
02500 
02600 
02700 
02800 
02900 
03000 
03100 
03200 
03300 
03400 
03500 
03600 
03700 
03600 
03900 
04000 
04100 
04200 
04300 
04400 
04500 
04600 
04700 
04800 
04900 
05000 
05100 
05200 
05300 
05400 
05500 
05600 
05700 
05800 



RESTRICTIONS 



THE PROGRAM MAY NOT 
CALLED. THIS HILL BE FIXED 
ACCIDENTLY OVERLAYS »'OWN" 
ZEROED) IS fixed; 



BE RESTARTED AFTER 

WHENEVER THE LOADER 

DATA (INSTEAD OF 



TIMSETO IS 

BUG WHICH 

LEAVING IT 



ANY ROUTINE WITH A NAME SIX (OR MORE) CHARACTERS IN 
LENGTH WHOSE FIRST THREE CHARACTERS ARE "TIM'i WILL NOT BE 
TIMED EXPLICITLY, THIS TEST IS USED TO DIFFERENT! ATE 
ROUTINES' OF THE TIMING PACKAGE FROM THOSE OF THE USER'. 
SHOULD THE USER HAVE ANY ROUTINES OF THIS NATURE, THE TIME 
SPENT IN THEM WILL BE CHARGED TO THEIR CALLER, 

IF DDT IS USED TO START THE TIMING OFF (SEE BELOW), 
BREAKPOINTS MUST NOT BE PLACED AT ANY ROUTINE ENTRY POINTS 
BEFORE TIMSETO IS CALLED". IF ONE IS PLACED IN SUCH A 
POSITION, THE ROUTINE WILL NOT BE TIMED EXPLICITLY, BUT 
RATHER AS DESCRIBED ABOVE (FOR "TIMXXX" ROUTINES)', 
ESPECIALLY ONE SHOULD NOT PLACE A BREAKPOINT AT THE POPJ 
WHICH LEAVES THE ROUTINE, THE SIDE EFFECTS THIS COULD HAVE 
ARE TOO HORRIFYING To 



THE SIDE EFFECTS 
CONTEMPLATE, 



THE HIGH SEGMENT USED MUST BE PRIVATE, SINCE THE 
TIMINITO ROUTINE (CALLED BY TIMSETO) EXERCISES WRITE 
PRIVILEGES IN THE HIGH SEGMENT, 

THE ROUTINES MUST NOT CONTAIN SPURIOUS POPJ INSTRUCTIONS 
(WHICH CAN BE GENERATED BY USE OF THE MACHOP FEATURE IN 
BLISS). ONE, AND ONLY ONE# POPJ IS PERMITTED IN A ROUTINE*, 

IF A MACRO-10 SUBPROGRAM IS USED, IT MUST ADHERE TO THE 
BLISS LINKAGE DISCIPLINES IF IT IS TO BE EXPLICITLY TIMED". 
IN PARTICULAR, IT MAY CONTAIN ONLY ONE "PUSH SREGiFRE(!" 
INSTRUCTION WITH A LABEL, EITHER INTERNAL, OR EXTERNAL'. 
(NOTE THAT SUCH INSTRUCTIONS WITHOUT LABELS ATTATCHEO ARE 
VALID). IT MUST ALSO CONTAIN ONE AND ONLY ONE POPJ 
INSTRUCTION (SEE ABOVE RESTRICTION)'. VIOLATION OF THIS RULE 
WILL RESULT IN ABSOLUTELY UNPREDICTABLE BUT CERTAINLY 
INCORRECT BEHAVIOR OF THE PROGRAM BEING TIMED, 



THE LOCATION OF 
RUN TIME WITH A CORE 
TIMED ARE IN THE 



THE HIGH SEGMENT MUST NOT BE CHANGED AT 
OR REMAP UUO IF ANY ROUTINES BEING 

HIGH segment; The change will not be 

DETECTED BY THE TIMING PACKAGE AND CONFUSION AND CATASTROPHE 
WILL ENSUE. THE SI2E OF EITHER THE LOW OR HIGH SEGMENT MAY 
BE CHANGED, AS LONG AS THIS DOES NOT RESULT IN CHANGING THE 
ORIGIN OF THE HIGH SEGMENT', 

IF OUTPUT IS TO BE DIRECTED TO THE LINE PRINTER, ALL I/O 
IN THE USER'S PROGRAM MUST BE CORRECTLY TERMlNATEDi SINCE A 
"CALL CSIXBIT /RESET/]" UUO IS EXECUTED PRIOR TO EACH 
PRINTING. NOTE THIS ALSO RESETS JOBFF TO , J0BSA<18,18> AND 
SETS THE WRITE-PROTECt BIT IN THE HIGH SEGMENT, IF ANY OF 
THESE HAVE AN ADVERSE EFFECT ON THE PROGRAM OR DATA BASE. 
THEN PRINTER OUTPUT MAY NOT BE USED'. 
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USE FROM DDT 



THE TIMING PACKAGE MAY BE CALLED FROM DDT (RATHER THAN 
HAVING TC RE-ASSEMBLE THE MAIN PROGRAM MODULE) BY PLACING A 
BREAKPOINT IN THE MAIN PROGRAM. THIS BREAKPOINT MUST BE SET 

THE STACK HAS BEEN INITIALIZED, BUT BEFORE 
TO BE TIMED*, THE CALL TO TIMSET 
THE CONTEXT OF THE MAIN PROGRAM'. 
PLACED SOMEWHERE IN THE MAlN 
TO CEASE'. A GOOD PLACE, FOR 
THE END OF THE CODE. 



SOMEPLACE AFTER 
THE FIRST CALL ON 
FROM DDT MUST 3E 
A BREAKPOINT MUST 
PROGRAM WHERE 
EXAMPLE, "IS THE 



A ROUTINE 
MADE FROM 
ALSO BE 
TIMING IS 
"UUO 12" AT 



WHEN THE FIRST BREAKPOINT IS REACHED, TYPE "PUSHJ 
TIMSETSXf, THIS WILL CALL THE TIMSETO ROUTINE. WHEN 
CONTROL RETURNS, TYPE "$P" TO PROCEED'. WHEN THE SECOND 
BREAKPOINT IS REACHED, TYPE "PUSHJ tIMENDSX" TO TERMINATE 
TIMING. THIS WILL MARGINALLY INFLUENCE THE TIMINGS OF THE 
MAIN PROGRAM, SINCE THE TIME SPENT IN DDT AFTER THE REtURN 
FROM TIMSET AND BEFORE THE CALL OF TIMEND ARE CHARGED Tq THE 
MAIN PROGRAM. 

AFTER CONTROL RETURNS FROM THE SECOND PUSHJ, TYPE "PUSHJ 
TIMST#$X" (WHERE # IS ONE OF THE NUMBERS 1-9) TO OBTAfN 
OUTPUT OF THE STATISTICS, ALTERNATIVELY, ONE MIGHT TYPE 
"PUSHJ TIMALLSX" TO OBTAIN OUTPUT OF ALL THE STATISTICS. 

TO DIRECT OUTPUT TO THE LINE PRINTER, TYPE "PUSHJ 
TIMLPT5X", ALL OUTPUT WILL BE DIRECTED TO THE LINE PRINTER 
UNTIL REDIRECTED TO THE TTY BY "PUSHJ TIMTTYSX", THESE 
CALLS SHOULD NOT BE GIVEN UNTIL TIMENDO HAS BEEN CALLED'. 

TO AID IN SETTING UP A PROGRAM TO BE TIMED, A "PATCH 
FILE" MAY BE USED', THIS CONTAINS ALL THE DDT COMMANDS 
NECESSARY TO SET UP TIMING'. GENERALLY THESE CONSIST ONLY OF 
SETTING UP BREAKPOlNtS AND EXECUTING THE INITIALIZATION 
COMMANDS, BUT MORE COMPLEX OPERATIONS MAY BE NECESSARY, THE 
PROTOCOL BELOW SHOWS HOW TO SET UP AND USE A PATCH FILEi 



.MAKE PATl.DDT 

<K3&1\ DRIV,F + 4$B DR!V',F*5$B $G PUSHJ TIMSETSX $P\S$ 

»EX$$ 

EXIT 

to 

.GET DSK TIMING 

JOB SETUP 

tC 

.DDT 

$".PAT1.SY DRIV',F*4SB DRIV',F + 5IB $G 
SlB>>DRlV.F+4 PUSHJ TIMSETSX 

SP 



'^ 



J 



NOTE 
FILE ARE 



THAT 
TYPED 



AFTER 
OUT AS 



TYPING 
IF THEY 



$",PAT1".SY THE 
HAD BEEN TYPED 
8-8 



COMMANDS IN THE 
FROM THE TTY, 



06100 THE $Y C^YANK'M COMMAND IS MORE FULLY DOCUMENTED IN THE C-MU 

06200 DDT MODIFICATIONS WRiTEUP. IT IS RECOMMENDED THAT THE LAST 

06300 COMMAND IN THE FILE BE SP| AND THAt THE CALLS TO "TIMEND" 

06400 AND THE REPORTING ROUTINES BE PERPORMED FROM THE TTY; TME 

06500 MAIN REASON FOR THIS IS THAT IF DDT IS RE-ENTERED AT ANY 

06600 POINT BEFORE THE DESIRED BREAKPOINT OCCURS, THE REMAINDER OF 

067(50 THE FILE WILL BE READ WITH UNDESIRABLE SIDE EFFECTS, 
0680«>. 
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?5i?? ---METHOD or IMPLEMENTATION.-, 

THE TIMER IS READ BY USE OF A CALL ACiCSIXBiT /RUNTIM/3 
UUOi MODIFIED ACCORDING TO THE MEMO CIRCULATED DESCRIBING 
THE HIGH-RESOLUTION TIMER IMPLEMENTAT JON AT C-MU. IN 0RDE:R 
TO OPERATE CORRECTLY ON SYSTEMS WHICH DO NOT HAVE THE 
HARDWARE AND SOFTWARE MODIFICATIONS FOR THISi THE "TiMINT" 
PROGRAM WILL HAVE TO BE CHANGED TO THEIR SPECIFICATIONS, AS 
A WARNING. THE "JIFFY TIMER" OF THE STANDARD DEC SOFTWARE 
HAS TOO COARSE A RESOLUTION (1/60 OR 1/50 OF A SECOND) TO 
MAKE TIMING SHORT ROUTINES POSSIBLE, AND ALSO SUFFERS FROM 
THE FACT THAT INTERRUPTS FROM DEVICES GET CHARGED TO THE 
RUNNING JOB, REGARDLESS OF WHETHER THAT JOB GENERATED THE 
REQUEST OR NOT. 

ALL TIMING FIGURES GIVEN ARE IN "TICKS", WHICH ARE iZ 
MICROSECONDS EACH, HENCE THE 35-BIT INTEGER WHICH 
REPRESENTS TIME CAN COUNT 34,359,738,368 TICKSi OR 343,597 
SECONDS, MORE THAN ADEQUATE FOR ANY TIMINGS DONE. 

THE TIMINITO ROUTINE IS CALLED FROM TIMSET{) AND 
PERFORMS THE FOLLOWING ACTIONSI 1) IT TURNS OFF THE 
WRIIE-PROTECT BIT IN THE HIGH SEGMENTI 2) IT INITIALIZES 
CERTAIN COUNTERS AND CREATES AN ENTRY IN THE TIME VECTOR FOR 
THE MAIN PROGRAMI 3) SCANS THE DDT SYMBOL TABLE SEARCHING 
FOR ROUTINE NAMES (A NAME WHICH SATISFIES CERTAIN CRITERIA, 
BEST DISCOVERED BY EXAMINING THE CODE)! 4) CREATING AN ENTRY 
IN THE TIME VECTOR FOR EACH ROUTINE FOUNDI 5) REPLACING THE 
"PUSH SREG,FREG" INSTRUCTION AT THE BEGINNING OF EACH 
ROUTINE BY A "PUSHJ SREG.TIMENT" INSTRUCTION AND EVERY "POPJ 
SREG," INSTRUCTION AT THE END BY A "JRST TlMEXt" 
INSTRUCTION; AND FINALLY 6) IT !?£STORES THE HIGH-SEGMENT 
WRUE-PROTECT BIT TO ITS PREVIOUS STATUS, 

THE TIMING UPON ROUTINE ENTRY IS CALCULATED AS FOLLOWS"! 

GRAB TIMER (DONE IN TIMENT) 

COMPUTE LOST TIME 

ADD TIME INCREMENT TO ALL ACTIVE ROUTINES' TOTAL 

TIME 
ADO TIME INCREMENT TO CURRENT ROUTINE TIME 
PUSH THE NEWLY-ENTERED ROUTINE TJME VECTOR ONTO THE 

TIME STACK 
ADD 1 TO THE NUMBER OF CALLS 
GRAB TIMER (AGAIN DONE IN TIMENT) 

THE TIMING UPON ROUTINE EXIT IS CALCULATED AS FOLLOWSl 

GRAB TIMER (DONE IN TImEXT) 

COMPUTE LOST TIME 

ADD TIME INCREMENT TO ALL ACTIVE ROUTINES^ TOTAL 

TIME _^ 

ADD TIME INCREMENT TO CURRENT ROUTINE'S ROUTINE TIME ) 
POP THE TIME VECTOR. OF THE CURRENT ROUTINE ^ 

GRAB TIMER (DONE IN TIMEXT) 

LOST TIME IS THE TlME BETWEEN THE »»GRAB TIMER" BEGINNING 
A TIMING ROUTINE AND THAT AT ITS END'. 
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c 



06100 THE TIME VECTOR IS THE TABLE CONTAINING THE NAMES OF ALX 

06200 ROUTINES IN THE SYSTEMi AND AREAS TO ACCUMULATE STATISTICS 

06300 FOR THEM, IT IS CURRENTLY 6 WORDS PER ENTRY TIMES THE 

06400 NUMBER OF ENTRIES (MaXRTN) IN SIZE'. 
06500 
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00100 ---LOCALIZATION MEASURES-«- 

00200 r^ 

00300 LOCALIZATION MEASURES PROVIDE INFORMATION ABOUT THE 

00400 DYNAMIC BEHAVIOR OF A PROGRAM WITH REGARDS TQ ITS EXECUTION 

00500 WITHIN CERTAIN REGIONS OF MEMORY AND ITS DATA ACCESSES, THE 

00600 TIMER PACKAGE CANNOT OBTAIN STATISTICS ABOUT ITS BEHAVIOR 

00700 WITH REGARD TO DATA ACCESSES, BUT IT CAN MONITOR THE 

00800 INSTRUCTION LOCALIHaTI ON'. THESE MEASURES ARE USEFUL FOR 

00900 DETERMING THE PROPER GROUPING OF ROUTINES OR MODULES FOR 

01000 PAGING OR OVERLAYING'. 

01100 

01200 THE LOCALIZATION STATISTICS OBTAINED ARE SOMEWHAT 

01300 APPROXIMATE, SINCE THE ROUTINE IS AWARE ONLY OF THE BLOCK OF 

01400 MEMORY WHICH CONTAINS THE ROUTINE ENTRY POINT, IF THE 

01500 ROUTINE CROSSES A BLOCK BOUNDARY, THIS SHOULD COUNT AS A 

01600 BLOCK CROSSING, BUT DOES NOT, IT WOULD BE HOPED THAT A 

01703 BLISS VERSION FOR A PAGED PDP»10 WOULD HAVE A FACILITY TO 

01800 FORCE ROUTINES TO THE NEXT PAGE BOUNDARYi RATHER THAN SPLIT 

01900 THEM. 

02000 

02100 THE LOCALIZATION MONITOR RECORDS 1> THE NUMBER OF TIMES 

02200 A BLOCK WAS ENTERED (A ROUTINE WITHIN THE BLOCK WAS CALLED) 

02300 FROM A DIFFERENT BLOCK AND 2) THE NUMBER OF TIMES A ROUTINE 

02400 WITHIN THE BLOCK CALLED A ROUTINE IN A DIFFERENT BLOCK, FROM 

02500 THE REMAINDER OF THE TIMING INFORMATION, THE TOTAL NUMBER OF 

02600 CALLS WHICH WERE MADE TO ROUTINES WITHIN THE MEMORY BLOCK 

02700 AND THE TIME SPENT IN THESE ROUTINES IS OBTAINED. A SUPPORT "^ 

02800 ROUTINE PRINTS OUT A MEMORY MAP LISTING THE ROUTINES WITHIN -^ 

02900 EACH SLOCK. MORE SOPHISTICATED ANALYSIS IS POSSIBLE BY 

03000 EITHER PROGRAM OR HUMAN, 

03100 



D 
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021100 
00200 
00300 
00400 
0050^ 
00600 
00700 
006012 
00900 
01000 
01100 
01200 
0130.0 
01400 
01500 
01600 
01700 
01800 
01900 
02000 
02100 
02200 
02300 
02400 
02500 
02600 
02700 
02800 
02900 
03000 
03100 
03200 
03300 
03400 
03500 
03600 
03700 
03800 
03900 
04000 
04100 
04200 
04300 
04400 



LOCALiiATION OUTPUT 



THE L0CALI2ATI0N OUTPUT CONSISTS OF TWO ROUTINES, TIMST8 
AND TIMST9, WHICH MAY BE CALLED FROM THE USER^S MAIN PROGRAM 
OR VIA DOT IN THE SAME MANNER THAT THE OTHER REPORTING 
ROUTINES ARE CALLED (SEE "USE FROM DDT" ABOVE), 



TIMSTBO OUTPUT! 
BLOCK IN CUT 



CALLS TIME 



"BLOCK" IS THE MEMORY ADDRESS OF THE MEMORY BLOCK, IF 
NO TRANSFERS IN OR OUT WERE MADE. THEN THIS IS THE ONLY 
INFORMATION ON THE LINE. 

"IN" IS THE NUMBER OF CALLS MADE TO ROUTINES IN THE 
BLOCK FROM ROUTINES OUTSIDE THE BLOCK', 

"OUT" IS THE NUMBER OF CALLS MADE TO ROUTINES OUTSIDE 
THE BLOCK FROM ROUTINES WITHIN THE BLOCK. 

"CALLS" IS THE TOTAL NUMBER OF CALLS MADE TO ALL 
ROUTINES WITHIN THE BLOCK, FROM ALL OTHER ROUTINES 
("CALLS"-"IN" GIVES SOME MEASURE OF THE INTRA-BLOCK 
ACTIVITY), 

"TIME" IS THE TOTAL TIME SPENT EXECUTING ALL ROUTINES 
WITHIN THE BLOCK*. THIS IS THE SUM OF ALL "ROUTINE" TIMES 
FOR THE ROUTINES WITHIN THE BLOCK. 



TIMST9() OUTPUT; 

BLOCK RTNS 

««««•* «•«*•• *#•••• •*»••• «•«•«• «*«••• «•••«• 

• ••««• ••#••• ETC'. 

"BLOCK" IS THE MEMORY ADDRESS OF THE MEMORY BLOCK', 

"RTNS" IS THE NAMES OF ALL ROUTINES CONTAINED IN ThaT 
BLOCK. 



C 
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00100 ----INTERNAL DOCUMENTATION--.. 
00200 

00300 DATA GATHERING ROUTINESJ ^ 
00400 -^ 

00500 TIMENT: ALL ROUTINES LINK TO THIS ROUTINE UPON ROUTINE 

02600 ENTRY, THE CLOCK IS READ AND ITS VALUE IS PASSED TO 

0070^' TIMEINO', ON RETURN TO TIMENT THE CLOCK IS READ 

0'?800 AGAIN TO PREVENT THE TIME SPENT IN THE TIMING 

0^^900 ROUTINES FROM BEING COUNTED IN THE ROUTINE TIMES'. 

E1002! THIS VALUE IS STORED IN THE GLOBAL VARIABLE 

0il00 "TIMPPE"', TIMENT IS CONTAINED IN T IM INT , M AC AND 

01200 USES 14 WORDS, 

0130J 

01400 TIMEXT: ALL ROUTINES LINK TO THIS ROUTINE UPON ROUTINE EXIT". 

01500 THE CLOCK IS READ AND ITS VALUE IS PASSED TO 

01600 TIMEOUTO, ON RETURN TO TIMEXT THE CLOCK IS READ 

01700 AGAIN TO PREVENT THE TIME SPENT IN THE TIMING 

01800 ROUTINES FROM BEING COUNTED IN THE ROUTINE TIMES', 

0^^900 THIS VALUE IS STORED IN THE GLOBAL VARIABLE 

02000 "TIMPRE"; TIMEXT IS CONTAINED IN TIMINT.MAC AND 

02100 USES 11 WORDS, 

02200 

02300 TIMEIN; THIS ROUTINE IS CALLED PROM TIMENT AND IS PASSED THE 

02400 ROUTINE ADDRESS (PLUS ONE) AND THE CURRENT TIME'. 

02500 THE INCREMENT OF TIME SINCE THE LAST READING OF THE 

02600 CLOCK IS COMPUTED AND TIMACCO IS CALLED TO ADD IT 

^'?•lm TO ALL THE CUMULATIVE TIMES OF ALL OUTSTANDING 

02800 ROUTINES', THE INCREMENT IS ALSO ADDED TO THE 

02900 ROUTINE TIME OF THE CALLING ROUTINE, A TIME VECTOR 

03000 POINTER TO THE TIME VECTOR OF THE CALLED ROUTINE !S 

03100 PUSHED ONTO fHE TIME STACK AND THE NUMBER OF CALLS 

03200 IS INCREMENTED. ASSORTED STATISTICS ABOUT STACK 

03300 DEPTH, NESTING DEPTH, AND BOUNDARY CROSSINGS ARE 

03400 OBTAINED", USES 71 WORDS. CALLS TIMACC, TIMTRX, 

03500 TIMERR, TIMLOC*, 

03600 

03700 TIMEOUT! THIS ROUTINE IS CALLED FROM TIMEXT AND IS 

03800 PASSED THE CURRENT TIME', THE INCREMENT OF TIME 

03900 SINCE THE LAST READING OF THE CLOCK IS COMPUTED AND 

04000 TIMACCO IS CALLED TO ADD IT TQ THE CUMULATIVE TIMES 

04100 OF ALL OUTSTANDING ROUTINES', THE INCREMENT IS ALSO 

04200 ADDED TO THE ROUTINE TIME OF THE CURRENT ROUTINE'. 

04300 THE TIME VECtOR POINTER OF THE CURRENT ROUTINE IS 

04400 POPPED FROM THE TIME STACK', USES 23 WORDS, CALLS 

04500 TIHACC. 

04600 

04700 TIMACC: THIS ROUTINE IS CALLED FROM tiMEiN AND TIMEOUT AND 

04800 IS PASSED THE tiME INCREMENT TO BE ADDED, THIS 

04900 INCREMENT IS ADDED TO THE CUMULATIVE TIME OF ALL 

05000 ROUTINES POINTED TO BY POINTERS IN THE TIME STACK, 

05100 TAKING CARE NOT TO ADD tHE VALUE TWICE TO ROUTINES 

05200 CALLED RECURSIVELY*, USES 26 WORDS, 

05300 ^ 

05400 TIMLOC; THIS ROUTINE IS CALLED TO LOCATE THE TIME VECTOR OF ^ 

05500 THE ROUTINE BEING CALLED'. If RETURNS AS ITS VALUE ^ 

05600 THE INDEX OF THIS ROUTINE IN THE TIMEVECTOR 

05700 STRUCTURE, USES BINARY SEARCH TECCNIQUE, USES 25 

05800 WORDS. 

05900 

06000 TiMTRX: THIS ROUTINE IS CALLED FROM TImEIN TO RECORD 
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06100 BOUNDARY CROSSINGS". TAKES TWO PARAMETERS, THE 

06200 ADDRESS Of THE CALLED ROUTINE AND THE ADDRESS OF THE 

06300 CALLING ROUTINE, IF THEY ARE IN DIFFERENT BLOCKS, A 

06400 TRANSITION OUT OF THE CALLERS BLOCK AND ONE INTO THE 

06500 CALLED BLOCK ARE RECORDED^. USES 17 WORDS. 

06600 

06700 

06800 INITIALIZATION ROUTINES! 

06900 

07000 TIMSET: CALLS TIMINlTt), ON RETURN tl READS THE CLOCK AND 

07100 STORES THE VALUE IN THE GLOBAL VARIABLE "TIMPRE"*, 

07200 tHIS ROUTINE IS CONTAINED IN TIMINT.HAC AND USES 8 

07300 WORDS, 
07400 

187500 TIMINIT; THIS ROUTINE IS CALLED BY TIMSET(> AND 

07600 INITIALIZES THE SYSTEM BEING TIMED, IT OBTAINS 

07700 WRITE PRIVILEGES IN THE HIGH SEGMENT, PREPARATORY TO 

07800 PLACING TRAPS IN THE ROUTINES. IT THEN CREATES A 

07900 DUMMY ENTRY FOR THE MAIN PROGRAM (FROM WHICH JT 

0S020 ASSUMES IT WAS CALLED} SO THE MAIN PROGRAM LOOKS 

08100 LIKE A CALLING ROUTINE', SEVERAL COUNTERS AND 

0B200 SWITCHES ARE INITIALIZED'. THE DDT SYMBOL TABLE tS 

08300 SCANNED, AND EACH SYMBOL REFERRING TO A LOCATION IN 

08400 THE ADDRESS SPACE JS EXAMINED, IF THE SYMBOL AND 

08500 THE WORD IT POtNTS TO SATISFY CERTAIN CRITERIA, THE 

08600 SYMBOL IS CONSIDERED A ROUTINE NAME'. TIMFIX fS 

08700 CALLED TO PLACE ROUTINE ENTRY/EXIT TRAPS, AND AN 

08800 ENTRY IN THE TIMEVECTOR STRUCTURE IS CREATED', 

08900 FINALLY, THE OLD VALUE OF THE HIGH-SEGMENT 

09000 WRlTE-PROTECt BIT IS RESET', USES 179 WORDS, CALLS 

09100 TIMFIX, TJMMAK, TIMSRC, TIM50X; 
09200 

09300 TIMFIX: THIS ROUTINE IS CALLED FROM TIMINIT TO SET TIMING 

09400 TRAPS IN THE ROUTINE'. IT IS PASSED THREE 

09500 PARAMETERS! THE ADDRESS OF THE ROUTlNEi THE NAME OF 

09600 THE ENTRY-TRAP ROUTINE, AND THE NAME OF THE 

09700 EXIT-TRAP ROUTINE'. THE FIRST INSTRUCTION IN THE 

09800 ROUTINE JS REPLACED BY A "PUSHJ <ENTRY ROUTINE:^" 

09900 INSTRUCTION! THE POPJ TERMINATING THE ROUTINE tS 

10000 REPLACED 9Y A "JRST <EXIT R0UTINE>" INSTRUCTION'. 

10100 USES 29 WORDS. 
10200 

10300 TIMMAK: THIS ROUTINE IS CALLED TO CREATE A NEW ENTRY IN THE 

10400 TIMEVECTOR STftUCTURE, IT IS PASSED THE ADDRESS OF 

10500 THE ROUTINE AND ITS SIXBIT NAME. IF ADDING THIS 

10600 ROUTINE WOULD CAUSE THE TIMEVECTOR STRUCTURE TO BE 

10700 EXCEEDED, AN ERROR FLAG IS SET AND NO ENTRY !S 

10800 CREATED. USES 33 WORDS. 
10900 

11000 TIMSRC5 THIS ROUTINE IS CALLED BY TIMINIT TO OBTAIN THE NAME 

11100 OF THE MAIN PROGRAM, IT SEARCHES THE DOT SYMBOL 

11200 TABLE FOR EXACT EQUALITY OF ItS PARAMETER. USES 25 

11300 WORDS, 
11400 

11500 TIM50X: TAKES A RADIX50 SYMBOL (E'.C'. A DDT SYMBOL) AND 

11600 RETURNS AS ITS VALUE THE SlXBlT NAME, RIGHt 

11700 JUSTIFIED, USIS 25 WORDS'. 
11800 

11900 TIM506: TAKES A RAOIX50 CHARACTER AND CONVERTS IT TO A 

12000 SIXBIT CHARACTER'. USES t1 WORDS, 
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2100 

2200 

2300 TERMINATION ROUTINES! ""^ 

2400 —^ 

2500 TIMEND: READS THE CLOCK AND CALLS TIMEOUK) TO FINISH THE 

2600 TIMING OF THE MAIN ROUTINE', THEN CALLS TIMTOTO TO 

2700 FINISH COMPUTATION OF CERTAIN VALUES, USES 7 

280^ WORDS, THIS ROUTINE IS CONTAINED IN THE MODULE 

2900 TIMINT.MAC, 

3000 

3100 TIMTOT: CALLED BY TlMEND TO COMPUTE AVERAGE TIMES FOR EACH 

3200 ROUTINE. ALSO COMPUTES TOTAL EXECUTION TIME AND 

3300 TOTAL NUMBER OF CALLS, USES 57 WORDS, 

3400 

3500 

3600 REPORTING RQUTlNESl 

3700 

3800 TIMLPT: sets THE LPT SWITCH TO DIRECT OUTPUT TO THE LINE 

3900 PRINTER. 

4000 

4100 TIMTTY: resets the LPT SWITCH TO DIRECT OUTPUT TO THE TTY'. 
4200 

4300 TIMWLPTJ CALLED BY TIMPUT TO WRITE A CHARACTER ON THE 

4400 LPT, TWO PARAMETERS ARE PASSEDl A FUNCTION CODE AND 

^500 A CHARACTER. THE FUNCTION CODES AREl 0/ OPEN THE LPT 

4600 AND WRITE THE CHARACTER GIVEN', 1/ WRITE THE 

4700 CHARACTER GIVEN", 2/ CLOSE THE LPT (CHARACTER 

,4800 IGNORED)', USES 60 WORDS. 
4900 

5000 TIMPUT; WRITES THE SINGLE CHARACTER PASSED TO IT ON THE LPT 

5100 OR THE TTYi AS DIRECTED BY THE LPT SWITCH, USES i4 

5200 WORDS. 
5300 

,5400 TIMSPUT: writes THE STRING PASSED TO JT (AS 

5500 5-CHARACTER GROUPS) ON THE LPT OR TTY, VIA TIMPUT'. 

,5600 USES 37 WORDS, 
,5700 

5800 TIMCRLF: WRITES A CARRI AGE-RETURN/LINE-FEED PAIR ON 

,5900 THE OUTPUT DEVICE". USES 10 WORDS, 
6000 

6100 TIMTAB; WRITES A TAB ON THE OUTPUT DEVICE, USES 7 WORDS'. 
,6200 

6300 TIMPR6: WRITES THE LEFT-JUSTIFIED SIXBIT CHARACTER STRING 

,6400 GIVEN ON THE OUTPUT DEVICE'. USES 21 WORDS, CALLS 

,6500 TIMPUT. 
6600 

6700 TIMDE2: THIS ROUTINE IS CALLED TC DO NUMERIC OUTPUT, IT IS 

6800 PASSED 3 PARAMETERS, THE NUMBER TO OUTPUT, THE WIDTH 

,6900 TO OUTPUT IT, AND THE BASE TO CONVERT IT BY (2<» 

7000 BASE <= 10r. CALLS TIMDE2 AND TIMPUT', USES 31 

,7100 WORDS, 
7200 

,7300 TIMDEC: THIS ROUTINE IS CALLED TO DO DECIMAL OUTPUT. IT IS 

7400 PASSED TWO PARAMETERSr THE VALUE AND THE WIDTH'. ~^ 

7500 CALLS TIMDC2 AND TIMPUT. USES 40 WORDS, -^ 

itm 

7700 TIMOCTJ THIS ROUTINE IS CALLED TQ DO OCTAL OUTPUT', IT IS 
7800 PASSED TWO PARAMETERS, THE VALUE AND THE WIDTH^ 

7900 CALLS TIMDE2 AND TIMPUT. USES 40 WORDS, 

,8000 
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18100 
18200 
18300 
18400 
18500 
18600 
18700 
18800 
18900 
19000 
19100 
19200 
19300 
19400 
19500 
19600 
19700 
19800 
19900 

20000 
20100 
20200 
20300 
20400 
20500 
20600 
20700 
20800 
20900 
21000 
21100 
21200 
21300 
21400 
21500 
21600 
21700 
21800 
21900 
22000 
22100 
22200 
22300 
22400 
22500 
22600 
22700 
22800 
22900 
23000 
23100 
23200 
23300 
23400 
23500 
23600 
23700 
23800 
23900 
24000 



TIMRE2: PUTS OUT THE STATISTICAL INrORMATlON ABOUT TOTAL 
PERFORMANCE AND INDIVIDUAL ROUTINE PERFORMANCE; 
USES TIMPUT, TIMSPUT, TiMDECi TIMPR6, TIMCRLr, 
TIMTAB, TIMWLPt, USES 284 WORDS, 

TIMSTl! SORTS DATA BY NAME AND CALLS TIMRE2, USES TIMESORT 
AND TIMRE2, USES 12 WORDS'. 

TIMST2: SORTS DATA BY CALLS AND CALLS tIMRE2. USES TIMESORT 
AND TIMRE2', USES 12 WORDS'. 

TIMST3: SORTS DATA BY ROUTINE TIME AND CALLS TIMRE2, USES 
TIMESORT AND TIMRE2, USES 12 WORDS', 

TIMST4: SORTS DATA BY CUMULATIVE TIME AND CALLS TIMRE2, 
USES TIMESORT AND TIMRE2, USES 12 WORDS, 

TIMST5: SORTS DATA BY AVERAGE ROUTINE TIME AND CALLS TIMRE2. 
USES TIMESORT AND TIMRE2. USES 12 WORDS, 

TIMST6: SORTS DATA BY AVERAGE CUMULATIVE TIME AND CALLS 
TIMRE2. USES tiMESORT AND TIMRE2, USES 12 WORDS', 



TIMST7: SORTS DATA BY ADDRESS AND CALLS TIMRE2, 
TIMESORT AND T!MRE2. USES 12 WORDS. 



USES 



TIMST8: CALLS TIMSCN, SPECIFYING TIMTRP AS THE PROCESSING 
ROUTINE. USES 8 WORDS, 

TIMST9: CALLS TIMSCNi SPECIFYING TIMPRT AS THE PROCESSING 
ROUTINE, USES 8 WORDS, 

TIMALL: calls TIMSTl THRU TIMST9', USES 14 WORDS, 

TIMSCN; CALLS TIMESORT TO SORT DATA BY ADDRESSES, SEQUENCES 
THRU THE ADDRESS SPACE IN BLOCKS OF 
2»»C0REBL0CK, CALLING THE REQUESTED ROUTINES 
(PASSED BY Its CALLER). USES TIMSPUT, TIMCRLF, 
TIMWLPT. USES 68 WORDS. 

TIMTRP: FOR EACH CORE BLOCK FOR WHICH THERE IS A TRANSITION 
IN OR OUT, PRJNT THE NUMBER OF EACH KiNDi THE TOTAL 
TIME SPENT IN THE BLOCK, AND THE TOTAL NUMBER OF 
CALLS TO ROUtlNES IN THE BLOCK, CALLS TJMSPUT. 
TIMDECi TIMOCTi TIMCRLF. USES 79 WORDS, 

TIMPRT; FOR EACH BLOCKi PRINTS OUT THE NAMES OF THE ROUTINES 
IN THAT BLOCK, USES TIMOCT, TIMTAB, TIMPR6. 
TIMCRLF. USES 50 WORDS, 

MISCELLANEOUS ROUTtNESl 

TIMESORT? SORTS tHE TIMEVECTOR DATA BY CREATING A 
SORTED INDEX VECTOR INTO THE TIMEVECTOR, THE SORT 
FIELD IS SPECIFIED BY THE PARAMETERS, THE 5 
PARAMETERS REQUIRED ARE» i) NUMBER OF ENTRIES TO BE 
SORTED; 2) WHICH WORD OF THE TIMEVECTOR TO SORT ONl 
3,4) THE POSITION (3) AND SIZE (4) FtELD 
SPECIFICATIONS OF THE BYTE OF THE WORD TO SORT 0N| 
5) THE OtRECtlON TO SORT', THE ALGORITHM IS A 
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24100 
24200 
24300 
24 4 00 
24500 
24600 
2470^! 
24800^ 
24900 
25000 
25100 
2520J 
25300 
2540a 
25500 
25600 
25700 
25800 
25900 



TIMS I FT 



GENERALI2ATI0N OF FLOYD'S TREESCRT 3 (ALGORITHM 249# 
CACM DEC, 1964), IT CONTAINS FOR ITS EXCLUSIVE USE 
THE ROUTINES TIMSIFTCSS WORDS) , TIMCMP (30 WORDS), 
TIMXFR (11 WORDS), TIMEXCH (l9 WORDS), TIMESORt 
ITSELF IS 53 WORDS LONG, 

SEE TIMESORT', 



O 



1 IMCMP: SEE TIMESORT*. 

TIMXFR: S.EE TIMESORT'. 

TIMEXCH: see TIMESORT', 

TIMERR: A GENERAL ERROR-CATCHER, ANY ERROR DETECTED CALLS 

TIMERRi PASSING IT AN ERROR CODE, THE CODE IS USED 

IN A SELECT EXPRESSION TO CHOOSE THE APPROPRIATE 
ACTION. USES 48 WORDS. 
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